Replace many of the global $theme/$theme_key with a call to the theme negotiator.

is there any new patches?

1. Why do we need to change all those service definitions here?

2. I actually wonder whether ThemeNegotiator is the right service to consult.

   And/or, in general, I've the impression we have at least one or two too many theme services right now. Yes, all of them have a discrete purpose, but because they are decoupled, the theme is no longer synchronized between them.

   Synchronization is the exact purpose of a global variable: It is guaranteed to have the same value, regardless from where or how you access it.

   The lack of synchronization means that the following scenario is completely possible right now:

   Service A negotiates theme foo, but service B checks access to theme bar, service C renders content with theme baz, and service D doesn't even have themes foo, bar, and baz in the list of enabled themes. WTF? :)

   Thus far, we've been treating the theme system similar to the module system architecture, which makes some level of sense, but when it gets to the actual runtime behavior, then the theme system diverges in significant ways from the module system:

   There is only one theme at a time. In order to switch to a different theme, a whole bunch of related and dependent services need to be re-initialized for a different theme.

   [whereas that almost reminds of a Container scope...]

   IMHO, the next best step is to merge and consolidate various classes and services into a single:

   1. Theme negotiation + access + initialization are extremely tied to each other → that's one and the same thing. It's whatDoWeWantToUseToday() + canIUse() + use().
   2. Theme\Registry::init() must die → it manually initializes a theme out of nowhere (not even checking for access nor validating anything else).
   3. ThemeHandler is a base dependency for the consolidated service in 1) → it supplies and controls which options are available in the first place.
   4. But even ThemeHandler and 1) can get out of sync way too easily → upon every single change to ThemeHandler::$list, 1) MUST be re-instantiated.

   → Consequently, we should honestly ask ourselves if 99% of the functionality shouldn't be moved directly into ThemeHandler.