Working with a (same version) Python app is actually a secondary worry. I'm more bothered that, for example, Excel can't load 2 frozen servers which use the same Python.
A COM component is useless IMO if it restricts which other components you can use, or which client you use, and that's why I didn't allow inproc COM servers in py2exe up to now. But, since this problem doesn't occur with nonfrozen servers, it seems the import hooks are the problem.
I hope using the frozen module mechanism instead of import hooks will make this more tolerant.
But where are those modules frozen? How do they get installed in the already running Python? What if mulitple sets of frozen modules (with dups) want to install themselves?
I hope one could extend the FrozenModule table in an already running Python by adding more stuff to it. Isn't there already code in cvs which allows this?
It ties into Martin's earlier comments about threading models. It may be that the solution lies in using COM's apartment threading, instead of free threading. That way, the COM server could have it's own interpreter state, and the calls would end up in the right interpreter. Maybe.
But I don't understand the COM part well enough, and Mark's stuff supports free threading, not apartment threading.
Last I checked, win32all registers the components as ThreadingModel = both. As I understand this, both STA and MTA is supported (STA = Single Threaded Apartment, MTA = MultiThreaded Appartment). So marking them as STA should be safe if it is needed. Maybe Mark can clear the confusion?
I really brought all this up to try to widen the scope from extension modules which can easily grab an interpreter state and hold onto it.