There are some parts of the namespacing efforts that I don't think need to be backported. Stuff in extensions falls into that category for the most part. Nothing says that developers have to fully adopt the 4.0 code style when updating their code, the 3.x conventions should still work the overwhelming majority of the time and where it just cannot then the hard B/C break needs to be documented (though hopefully we've kept those to a minimum).

Let's not try to force stuff here where we don't need to. Honestly, it's great that we are doing feature backports, but since the class mapping layer won't go away until 5.0, things that don't already fit into something we're doing in 3.x shouldn't be forced in.

It would lead then to the situation that extension devs can only used the none namespaced classes from the core extensions, even in Joomla 4. My stand on this is, if we can support it, why not, it will not hurt anybody.

Afaik, the goal is that extensions written for 3.9 are running in 4.0.
The goal is not that extensions written for 4.0 work in 3.9.

We shouldn't make it more complicate than needed. Backport what is needed for extensions to work also in 4.0. That is mainly the stuff where we break B/C with 4.0. But other than that, we don't have to backport anything into 3.9. There is no need to already support namespaced extensions in 3.9.
Imho, we already backported more than what is really needed, but it was simple and doesn't hurt so far.

I wouldn't expect that my namespaced extension works in 3.9. I will write an intermediate version of my extensions which work both in 3.9 and 4.0 and then the following versions will work only in 4.0. The namespacing isn't the only incompatibility anyway. There will be more features that are only available in the J4 series that are not (and should not be) backported into J3. Look at namespace as a J4 feature and it makes more sense 😄

It would lead then to the situation that extension devs can only used the none namespaced classes from the core extensions

This is not a problem. The old class naming schema is generally being supported until 5.0 so whether a developer is using "old" global class names or "new" namespaced class names doesn't really matter.

even in Joomla 4

This is only true if they intend to continue support for 3.x in their code as well. If they are only supporting 4.x they can use all newer conventions without consideration for legacy constructs.

There is nothing that says we have to backport all new features and logic into 3.8 and 3.9. We should backport stuff as logical, but we shouldn't be operating under the assumption that only backported features can be used in both 3.x and 4.x. On the contrary, except for where we know we are making hard B/C breaks, existing 3.x logic should just work without change on 4.x and developers should have to opt in to new 4.x features and conventions beyond the hard breaks.

I'm with @babker on this one. 4.0 will include namespacing and many more features but it's designed as a stepping stone imho to the future of Joomla! Once the devs are on 4.0 then they could include a 4.0 specific update which is namespaced. hopefully we provide an intial path to the 4.0 update so seemless that it will only be a few months after 4.0 is out that we can start to roll out specific 4.0 extension, since nobody will be using 3.... 😅

We are not talking here about new features. It's about classes of core extensions which do exist in Joomla 3 and 4, just with a different class name.

You mean a 3rd party extension which makes use of eg a model from com_content?
I wouldn't expect such an extension to be able to call the namespaced com_content model in J3.9. If anything, the non-namespaced class should work in J4. But honestly, I would expect that extension to use class_exist (or Joomla version) checks.
Keep in mind the B/C promise we give is about library classes, not extension classes. Extensions which interact with core extensions directly will always have to verify the classes they use are available.

On a sidenote: If your concern is about 3rd party extensions extending core component classes, then I'm tempted to say let that code break. Because really they MUST NOT do that.

There are reasons where it makes sense. For example when you want to have a custom field plugin you extend Joomla\Component\Fields\Administrator\Plugin\FieldsPlugin on J4 and J3 FieldsPlugin.

There will be no way for the extension developer use the same code base in J3 and J4, which would lead to a situation that every custom field needs to be shipped with two versions.

True, I give you that. Should only be a few such cases thought.
In that case I would not backport the namespaced name but keep the legacy one in J4 (either as classmap or stubfile, whatever works better).

That's what we do actually. Honestly I would like to see that we actively push to namesapced. If we do some backported classmapping then the acceptance of namespaced extensions will even be higher.

The only extension classes that IMO should be given consideration for 3.x mapping are FieldsPlugin and FinderIndexer*, which are classes that should be library level code anyway. We don't need to support class mapping each core component's MVC classes, form fields, or miscellaneous helper files. If it's proving to cause too many compatibility issues, I would make the older global namespace class names continue to work in 4.x for extensions on a case-by-case basis versus trying to fully classmap all of the core extensions.

The compatibility layer is keeping the old class names working, supporting new class structures in 3.x is just a bonus. There is no mandate that everyone jump to namespaces right away (even though we'd prefer it to be that way, let's be real here).

I love the Idea of writing/designing extensions for J4+ yet allowing them to be compatible with J3.8/3.9.
Designed for J4, runs on J3.x+ would be a great thing.

To design an extension for 4.0 and run it on 3.x, you use the existing conventions. Except for the UI layer rewrites and the removal of deprecated code, all existing logic still works. That's the backward compatibility policy at play here.

Where it makes sense, we can and should evaluate backporting features/functionality. But that doesn't mean it is a requirement or that everything will be ported. But there should be no requirement that to write a 4.0 extension that you can only work with new logic introduced in 4.0. The way I look at it is to take an existing extension's code base that runs on 3.x without using deprecated functionality and get it running on 4.0, it should require as minimal change as possible, and the developer can opt in to newer functionality as they phase out support for the 3.x line.

So focus one should be ensuring that migration path stays smooth (com_patchtester's current code supports 3.7 up to and including 4.0 with only one version conditional, and on a quick inventory of a more complex multi-view component we use at my company, in its current 3.7 state it should require zero code changes, and this excludes knowing the core UI has changed). Focus two is evaluating possible items for backport and where it makes sense bringing those changes back.

For the component MVC classes, I do not see bringing those changes back as something that can be done without impacting stability and B/C in the 3.x branch so I am skeptical about merging code related to those efforts. Classes in the global namespace, as components using the core MVC layer today are, will still be supported during the 4.x lifetime. So to me there is no need to tell developers "you must namespace your code to run on 4.x" or to even give that impression. Yes, that is the preferred choice, and should be the documented practice, because the current convention is deprecated, but that is a change the developers can make at their leisure during the next major series lifetime (which if it's anything like 3.x will be 6-8 years minimum), not a change they have to make in the next 2-3 years.

Going to close this one - looks like all opinions have been shared and that most of the backporting has been done