Description
I'll try to split off #8712 into smaller parts to perhaps keep the discussion more focused.
Currently, tools that have backend-specific implementations are "registered" by defining them in their own backend module, and then overwriting the "original" class in the backend_tools. For example, backend_qt5.py contains
class SaveFigureQt(backend_tools.SaveFigureBase): ...
class ConfigureSubplotsQt(backend_tools.ConfigureSubplotsBase): ...
...
backend_tools.ToolSaveFigure = SaveFigureQt
backend_tools.ToolConfigureSubplots = ConfigureSubplotsQt
...and likewise in backend_gtk3, etc. Unfortunately, this means that things won't work if multiple backend modules get imported in the same process (unless they are imported in the right order). This is not a theoretical concern: multiple backend modules do indeed get imported in the same process when performing automatic backend fallback detection. (It is true that the actually used backend is typically the last one imported but this is certainly not something we guarantee in the future.) Therefore, I believe there should instead be some other registration approach that links the tool classes to the backends (such as the one proposed in #9941, but I'm not particularly wedded to this approach either). (Note that one cannot rely either on heuristics such as "the Tool defined in the same module as the backend", because e.g. the qt5 tools are defined in backend_qt5.py but the backend modules are in backend_qt5agg.py/backend_qt5cairo.py or even third-party qt5 backends.)
Extra points if the tool registration mechanism allows any tool class to be overridden on a per-backend basis.