Nice to have
ModelBasedImportConfiguration.handleModelPartChanged() is called from the thread of the commit in which the model is changed. The method clears the contents of its caches and refills them. In the meantime, the consumer can import changesets in its thread. In doing so, it queries the caches currently being rebuilt for the types it should import. Since the caches are partially empty, they do not contain the type. This is interpreted as, "These types will not be imported." As a result, those changes are lost. Later, there will be changes based on them. These can no longer be imported because of the inconsistency. TL-Sync is thus permanently broken and no longer transfers anything.
The public methods of ModelBasedImportConfiguration and ModelBasedExportConfiguration were made synchronized. This is on the one hand the method notifyUpdate. In this the cache is cleared and refilled. And secondly, these are the methods that use the cache.
As explained in the comments, this is not a complete solution. But the remaining problem exists only for applications where the part of the model that is relevant for TL-Sync is changed at runtime. And this happens in almost no application so far.
No test, as that would be disproportionately expensive compared to the solution. A longer series of transfers would have to be made using TL-Sync. During which the model would have to be changed. And even then, it is a matter of chance whether the test fails or "gets lucky" and goes through.