TYPO3 Core

@Christian I'll take a chance and close this one. Essentially, the argument is: FLUIDTEMPLATE is not an Extbase context - object implementations registration is an Extbase context feature.

A bit expanded: the argument can also be made that with standalone Fluid arriving, the view used in this particular object is even less of an Extbase context. It basically will run entirely off of Fluid's View that knows nothing about Extbase even existing (nor should it, nor should Fluid in general in the TYPO3 flavor, but that's another discussion for another time). Also: once standalone Fluid becomes our base we will automatically be getting a lot of new ways to replace these API classes of Fluid, per instance of Views. Among other things you can replace the template parser class that gets used. It would require some additional configuration (like for example passing an "implementations" array as part of the FLUIDTEMPLATE configuration array...) but it would do the trick and be quite a lot more flexible than triggering global Extbase implementations registering.

That being said I do think we need some way of affecting these implementations (on a per-extension/package level). Perhaps you will be inspired by https://github.com/FluidTYPO3/flux/pull/1038 and agree we should create a similar pattern for TYPO3 itself (only speaking of the "implementations" part of the linked pull request, but I would suggest wrapping it in a class that can be detected by convention and basing it on a manifest of sorts - not the "extra" section of composer.json but an actual TYPO3 package manifest). I would also consider adopting the CompatibilityRegistry - I'll be proposing that in a coming merge request. And after all that I would begin replacing as many current usages of ext_typoscript_setup.txt as possible with package implementations. IMHO it would be quite nice indeed to be able to declare a manifest of implementations you want to use and even define those in a "when TYPO3 version is at least X use my Y implementation" way.