I'm not sure this is required? Is the dispatcher really going to help with anything in J3?

Well I hope the plan is not to completely remove the current entry point file in 4.0. That would probably be one of the more painful backward compatibility breaks. But, including it as a means to write forward compatible code is a good idea.

No it's definitely not the plan to remove that entry point. Probably ever. Because for some people an entry point even as generic as the dispatcher interface may not be good enough. It also forces GPL virality which isn't a requirement at the moment (if you avoid calling any core joomla function). So I don't foresee even deprecating the existing entry point. This dispatcher is just a new option

My idea is to move the JControllerLegacy::getInstance functionality out to the dispatcher when the component is namespaced. That's why the dispatcher is needed in 3.8 as well.

The dispatcher cannot be the only thing that does this - I mean it kinda depends on situation but I don't see why other things shouldn't be able to create a controller instance (e.g. a module or another controller instance etc).

This is why I think we need factories for at least controllers and models. The dispatcher then calls the controller factory and we could also proxy getInstance to the factory for 3.x and 4.x without huge b/c breaks

Of course they can, but then they should create the instance directly as it is very likely that they now the exact controller they want to load. Controller::getInstance() is only used to parse the command from the input, load the class and create the controller.

Is there a place where all of that is needed except in the entry file? At the moment it isn't in core.

Now you're getting into another architectural problem in general. That particular getInstance() method only returns a single application wide singleton. So you couldn't use it even if you wanted to in order to grab another controller.

If you ever tried writing a plugin to manipulate MVC layer behaviors (i.e. add alternate lookup paths for view classes to add either custom HTML behaviors or add a new view format for an existing component without just dumping it in the component's views directory), it's a massive pain in the backside because if your plugin doesn't do the right checks (and so many plugins don't do basic sanity checks to begin with) it breaks everything pretty catastrophically.

Don't know what this problem has to do with the dispatcher. Because the controller is not loaded trough getInstance() and then there is no singleton available?

You can't do multiple controllers with the current MVC layer and its getInstance method. It is one singleton for the entire request. Unlike other places where we have an array of singletons based on the data passed into their respective factories.

The dispatcher does nothing to address that. But if you ever did want to implement a structure where multiple controllers could be used in a HMVC like manner that is one place that needs major attention.

Closing as the dispatcher will be used only in J4 as done in PR #13953.