Ran into a rather ugly snag when testing MC3.0 using the newly released Sacred East 1.6 (development work was done using Sacred East 1.5)
The problem is technical and involves the way the game engine uses internal references to identify reference items, and stores those values in the .esm file (which by intent, was supposed to be a finished product and not subject to change). However, TR uses a master file, but is a work-in-progress... so those internal values are changing with each revision, and any mod that uses a global search and replace - which MC uses heavily - will be broken every time the master file is edited and all the internal reference values are recalculated.
The worst part of the problem is that when an object from a master file is replaced, the old copy is deleted and a new copy is added. When the internal references change, the mod can no longer find the original object to delete, BUT it still is able to place the new copy. This leads to doubling, and a global search and replace is no longer able to resolve the situation. Since there isn't a global delete, and deleting the master object WILL delete all the references in the game world, but it comes with it's own set of problems, the restored old objects have to be located and deleted by hand, one-by-one.
Needless to say this is an extremely long and tedious process which, unfortunately, will need to be repeated every time a new revision of the TR master file comes out. I'm not looking forward to that. In fact, I'm putting the project temporarily on hold until an acceptable solution can be found.
[edit] worse news: I was wrong about the game engine not being able to find the original object to delete. The internal references don't seem to be tied to any object ID at all, so when it decides to delete something, it deletes it by number and not by ID... so the correct number of objects are being deleted, but it's a crap-shoot as to which objects it actually deletes! This is becoming a nightmare, and being unable to know in advance what items are going to be deleted is something of a game-breaker. We've put out some requests for info, but unless a solution is found, I'm at a complete impasse.