This problem only occurs in the following scenario:

1. Setup IGTLConnector in OpenIGTLinkIF of Slicer as a client
2. Start TrackerServer as described in https://www.slicer.org/w/images/f/f1/OpenIGTLinkTutorial_Slicer4.1.0_JunichiTokuda_Apr2012.pdf
3. Start MITK TrackingToolbox and use Open IGT Link Connection as Device, Auto Detection, Connect

When only using step 2 and step 3 everything works as expected.

@mittmann: Is there a reason that we have to setup an IGTLConnector in Slicer for testing the use case of MITK as a client? Or is that another valid use case that should be tested?

The use case of MITK as client can be tested by using two MITK instances (one as server, one as client), as well. So, the described use case above seems to be another valid use case that should be tested. Additionally, the reported error does not occur only in the situation described. It occurs in other situations, as well (i.e. sometimes: use virtual tracker --> start and stop tracking --> close MITK --> open MITK --> virtual tracker tool is preset --> change from virtual tracker to another tracker (NDI Aurora or others) --> do not reset preset tools --> try to start tracking --> mentioned error message occurs.)

That's right. But this is a necessary check whenever one tries to connect to a tracking device with a tool storage loaded that was created for a different device. So this error message is actually valid in the case you describe it.
The question was whether the workflow I described in the previous comment (which is actually taken from the OpenIGTLink test protocol) is actually a valid test case as there seem to be two clients (Slicer and MITK) connected to the same server.
When only using the TrackerServer as server and MITK as client, everything works. The use case you describe where MITK is used both as a server and a client works as well.

Adapted test protocol and omitted Slicer connection.