I thought this shouldn't be a problem - that as pythonxx.dll contains a manifest with the references and also contains hoops to ensure its "activation context" is used when loading dynamic modules, that things should work correctly.  The scenario you outline isn't that different to Python being used as a COM server - where a program like "cscript.exe", which comes with Windows but I'm pretty sure has no reference to the CRT manifest we care about, loads up a Python COM object, causing Python to be loaded and it to load extension modules - and that works correctly.

That said though, I agree it would be nice if the manifest handling was optional, but it isn't immediately clear how that could be done given how distutils is structured.  Indeed, there isn't even an obvious way to do it programatically other than by monkey-patching the compiler class.  At least if you do take the monkey-patch route, you should find it necessary to only patch one fairly small method in the class.