I would even go that far that the plugin can't be disabled as it will not add a new installed extensions classpath to the list then.

I would even go that far that the plugin can't be disabled as it will not add a new installed extensions classpath to the list then.

Then a plugin is the wrong thing for this solution and it should be moved somewhere else (hint, if this needs to be an event listener our event dispatcher is not hard coupled to plugins; make it a standalone event subscriber class and in the dispatcher service when it is created add this subscriber to the dispatcher)

Yes, I was always saying that a plugin is the wrong thing for that use case. There is no reason to have that as plugin. And this was before we introduce the boot functionality, as we can now put the responsibility back to the extension while we have now a common path to load an extension. So we can avoid situations like #20823 and can get rid of all the balast of loading all extension namespaces into the classloader on every request even though we do not need all of them.

When I made the plugin "protected" I had hoped there was also a way to make it permanently enabled butt there isnt

I've pointed it out somewhere before but the plugin manager doesn't account for the protected column's value.

I would remove the plugin and move the classmap generation step somewhere into the installer as the classmap is essential part of the core (I still do not agree with the whole thing, but this is another story). For safety we can add a check in the application execute process too. But having that in a plugin is too dangerous for me.
About the issue of a none writable folder, what about a fallback to cache?

If you guys agree to remove the plugin, then I will do a pr next week.

Guys any news on this? In release 4 alpha 5 when installing a new component, it's namespace is not 'readed' from container. Must manually include it's path in file: libraries/autoload_psr4