Reading this just made me realize something. Are we sure there isn't a com_dispatcher floating around out there, because this new component dispatcher code and the stuff being added to the component helper essentially makes that a reserved name that cannot be used for components. And if there is, how do they address this change?

The only possibility is to change the logic, when the class MyComponentDispatcher doesn't exist not to throw an exception.

Well, it's not going to work that well. https://github.com/joomla/joomla-cms/pull/19616/files#diff-de12eb0832bf72d6f5d429fc68b1664cR355 includes the file, and if it's the current procedural entry point file that all components use then the component is going to be executed before you even get the chance to check for class existence. I haven't dug into it yet (honestly the issue only came to mind this morning), but right now I'm not seeing a way to do this without making com_dispatcher a blacklisted component name, and we need to find out if there is such a thing floating around (at a minimum if someone from JED could tell us if something is registered with that name it'd be a start, but that still won't account for all the custom dev on sites).

Then the philosophical debate turns to whether such a restriction counts as a B/C break and inherently could block entirely backporting this unless we breach our own rules.

Valid points. I will get in touch with the JED team to see if there is an extension like that.

Then the philosophical debate turns to whether such a restriction counts as a B/C break and inherently could block entirely backporting this unless we breach our own rules.

I mean this was no different to when we introduced com_tags or com_contenthistory (ok technically before we officially introduced semver but you get the point). It's no difference to core adding a new extension of any form. I think getting in touch with JED is a sensible idea - but I don't think it's a showstopper either - we just need to be proactive. There are some alternatives we can do too. If the class doesn't include

My question on this is how many extensions there are that override the constructor in controllers without calling parent::__construct - in 4.x I didn't mind taking this risk but obviously things are different in the 3.x series. My gut is telling me that we can add it as a constructor parameter if we want but not to actually use it inside the controller ourselves to cover this case. It's not a massive problem if we can't DI inject applications - the tests in the 3.x series aren't going to really change to take advantage anyhow

Something I've wanted to take a look into in the 4.x series (and I guess now's the time before we backport) is this context name for namespaced classes. It makes for pretty grim reading.

Finally I want to look at the unit test change you made I commented on. That seems like an outright b/c break.

JED can't answer properly as it looks like they do not have that information anymore.

Regarding your concern about injecting the app and input. We had that discussion already in #18351 and the PLT agreed to not count new constructor/function arguments as a BC break. So all extensions which do not call the parent constructor will break anyway because of the MVCFactory in 3.9. If we add the app and input doesn't mater anymore then.

Regarding your concern about injecting the app and input. We had that discussion already in #18351 and the PLT agreed to not count new constructor/function arguments as a BC break. So all extensions which do not call the parent constructor will break anyway because of the MVCFactory in 3.9. If we add the app and input doesn't mater anymore then.

We did - sorry forgot about that one. I'm good with that then.

Can we put this one on hold till we finalised the component service loading.

Obviously we still want to do this in 3.10 - but closing until we've got everything going in 4.0 then we'll re-open it as a new PR