Current functionality allows for overriding the core Template class with a new Template class. It is not clear if such overriding class SHOULD bear the same name or MUST bear a different one. It is also not clear how the platform will handle calls to the Template class which are not known to the core, nor which are obsoleted by the new class.
But the biggest problem is that such overriding class will act system wide, while the core Template class is tightly integrated with the core (f.i. template_options).
Suggestions:
Adjust the core template class to copy (on construct) the integrations in a protected $options array, in stead of referring all the time to $_TEMPLATE_OPTIONS. It has benefits to do so, because then these options cannot change between calls.
Add an optional parameter to the COM_new_template call containing the plugin name; forward that to the function to override the Template.
Or, alternative to (2), make the function to override the template class dependent on the plugin doing so.
Add a magic __CALL method to catch errors when calling the wrong template class. This method could forward calls to non-existing methods to a utility function, say OVERRIDEN_methods_template.
Current functionality allows for overriding the core Template class with a new Template class. It is not clear if such overriding class SHOULD bear the same name or MUST bear a different one. It is also not clear how the platform will handle calls to the Template class which are not known to the core, nor which are obsoleted by the new class. But the biggest problem is that such overriding class will act system wide, while the core Template class is tightly integrated with the core (f.i. template_options).
Suggestions: