Another idea is to leave the initialization / service registration / .xml-file changing inside the MouseModeSwitcher (everything hard-coded).
In our BlackSwan context we might use a different display interactor (interaction broadcast - only sending events). But, it will be initialized and registered as a service at another location (e.g. inside the CustomMultiWidget). Furthermore we do not allow to change the .xml-file (for the mentioned reasons - do not force a custom display interactor to handle all .xml-files) so we don't even need a mouse mode switcher. Our custom multi widget could just live without a mouse mode switcher so we don't need to adapt it for our needs.

Combining the best of both worlds we could stick with the mitk::MouseModeSwitcher as long as switching the mouse mode is its only responsibility.
That means, we need to remove the instantiation of a certain display interactor from the mouse mode switcher. Also we don't need to be able to initialize different types of display interactors as this is not the responsibility of this class.

Using the latest broadcast approach from T24216 we can also make sure that all .xml-files are correctly handled: We only have one broadcast class that connects each action of the config files to internal functions. If we don't want to handle a certain action, we must simply not react on the corresponding event that is sent from the broadcast class. That means an observer that receives events form the broadcast class can simply do nothing on this event.
However, we need to make sure that our broadcast class can send events for each action defined in the .xml-config files (we possibly need to define new events). But this has to be done with the current approach anyway: Each new action that is defined in the .xml-file needs to be connected with a (possibly new) member function of the mitk::DisplayInteractor.

Several flaws in the design of 'QmitkMouseModeSwitcher' and 'mitkMouseModeSwitcher' were spotted.
These should be solved in: T24356