Looks good. Only a couple notes.
Can we please place it here:

$router = new SiteRouter($container->get(SiteApplication::class));
$container->get(DispatcherInterface::class)->dispatch(
  'onAfterInitialiseRouter',
  new AfterInitialiseRouterEvent('onAfterInitialiseRouter', ['router' => $router])
);
return $router;

This way it will be more modular, and consistent when at some point we decide to extend it to another Routers.
And keep __constructor clean.

Another note. As @wilsonge already wrote.
Please remove PluginHelper::importPlugin it should be already imported outside (actualy it already done in App initialisation), if it not then it not a Router problem.

@Hackwar please move the event dispatching out from the constructor, keep the constructor "light", then it is good to go ?

It may looks a simple solution to place it there, but it will give a lot of headache to refactor this code later.

@Fedik While I disagree with the change, it's not the hill I'm going to die on. As requested, this has been implemented.

Visiting a home page, got an error:
SiteRouter not set in Joomla\Plugin\System\LanguageFilter\Extension\LanguageFilter from

I have tested this item ✅ successfully on 222e9ae

Works now.
Vielen Dank!

I'm not happy with https://github.com/joomla/joomla-cms/pull/42692/files#diff-efd8fc556b2cba4f15f336f73a194fd64fbb0b0a8fbb6c4478e87804b6f3ce48R740 yet.

I see, but you already set the router at

So you probably can revert $this->getApplication()->getRouter() back to $this->getSiteRouter(), because this code runs only for site application, or?

I'm not happy that we have the get/setSiteRouter at all and I don't like the order in which this is set. I would either keep it the way it is with the getApplication()->getRouter() or get it directly from the DI container. But someone decided that we should deprecate the getRouter() and at the same time it is frowned upon to get this from the container directly. But the get/setSiteRouter also is nasty. Why do we have this for one specific application router? Why shouldn't we have this for all applications? And with this being called when the plugin is instantiated, the router is created before the system plugins are loaded, thus making it impossible to run a system plugin on the onAfterRouterInitialise event. It basically is just a matter of time when a third party extension uses this code and thus breaks this feature.

You should not need an application to get the router from it. As only the SiteRouter is needed to create different urls, I decided to create that one first, if over time we need some other ones for more applications, then feel free to create new services.

I have tested this item ✅ successfully on 222e9ae

Fine for me. Did a core review and also tested the functionality of the new event in the depending PRs.

RTC

In the maintainer meeting we discussed this PR and agreed on adding a notice to the global configuration that there are additional settings in the SEF system plugin. This has been added to this PR now.

@Fedik @SniperSister would you be able to test this again?

Surely this is not what you intended

I have tested this item ? unsuccessfully on 07c4e6a

Has been fixed.

It should be rendered the same as other descriptions eg

I would agree with you, however the global configuration code doesn't allow that. I'm going to revert the whole notice part and this apparently will have to go into an additional PR.

I have tested this item ✅ successfully on eafa7fa

I have tested this item ✅ successfully on eafa7fa

I've re-tested the PR after the latest changes, works as described.

RTC

Would appreciate feedback and testing on this proposal for the additional note in global configuration #42832 @Hackwar

Thank you @Hackwar and also for testing and review @Fedik @laoneo @SniperSister @wilsonge @brianteeman