This is a nice improvement, can you fix the conflict so we can move forward with review?

We'r actually discussing if we should namespace the libraries folder in the 3 series or only in J4. This PR is an example how it would look like then. Either way we namespace the whole libraries folder in 3.8 and remove the classmap in 4 or we do it in 4 and then have to support the whole none namespaced stuff during the 4 lifecycle, means on every request in J4 the huge classmap file will be loaded.

I think the sooner we get this done the better. (I'm also blind to any possible negatives to that approach)

I prefer also to clean the house in J4, but not everybody agrees in the J4 team.

As long as there is a reasonable upgrade path for users/admins and we make it reasonable for developers to maintain/upgrade their 3rd party code we should clean as much as possible. Too many or too complex B/C breaks in past versions have turned off users/admins/developers.

The major downside to trying for a "clean slate" approach in 4.0 is no 3.x release (including 3.7) will have any form of compatibility with 4.0. If that plan is followed through on, only 3.8 would have compatibility and 4.0 would remove most of that "legacy layer". So while it'd be true that you could achieve 3.x and 4.0 compatibility in extensions by only supporting 3.8, I don't agree that making that bridge exist for such a short lifespan is a good idea. Projects like WordPress, Symfony, and Twig (hell, anything led by Fabien Potencier basically) eat a lot of technical debt to not alienate their userbases with major upgrades (in the case of Symfony 3.0 and Twig 2.0 the only remarkable things about those major releases were the removal of some deprecated code, deprecating some legacy layer stuff for the next major version, and bumping their minimum dependencies).

We're talking mostly about class name aliases here, not a functionality bridge. Is it really that expensive to keep that classmap through the lifetime of 4.x to make upgrades for developers and end users a little easier?

Please don't try to create 3.8 as a bridge to 4.0. That will not go down well both with extension developers and users.
4.0 will have some legacy code until 5.0. That's completely natural when using SemVer. The only way around that would be to plan forward, and by that I don't mean "Lets see what we want to do in 4.0 and then when implemented backport it into the last previous minor release".

Just keep those classmaps in 4.0. It will not hurt at all.

As it looks like most people agree that we should keep the classmap in J4, I'm totally fine with that.

Why I propose to namespace the whole libraries folder in J3.8? When as extension developer I want to keep the same code base for J3 and J4 then I have always to use the none namespaced core classes, even when we arrive at 3.8.28, two years after 3.8.0 is released. We just have to be clear about that.

That's why I suggest to namespace the libraries folder already in 3.8. We don't even have to change the core extensions to use them in 3.8 (I'v reverted that commit now).

I'm saying that, because now we have the situation where we still can namespace and merge it easily into the 4 branch. I guess the opposite will son not be possible.

The namespace stuff should most definitely be backported for 3.8. I just don't think the class map should be dropped in 4.0 is all.

I'm not convinced but clearly in the minority here. Le merged