python.exe already has the manifest it needs, but it can't be embedded into python27.dll - it has to go into the exe file. That's why Python can't make it so that msvcr90.dll is loaded.

Depending on what you're using it for, the C Runtime may keep some state in between function calls. For things like string copying (with no locale) you'll be okay, but most of the complication stuff assumes that every call into the CRT is calling into the *same* CRT. When you load different CRTs at the same time (as is happening here already, or when you load mscvrt.dll directly), you have to be very careful not to intermix them together at all.

The most obvious example is open file handles. If you open a file with CRT 9.0 (msvcr90.dll) and then try and read from it with CRT 6.0 (msvcrt.dll), you'll probably crash or at least corrupt something. The same goes for memory allocations - if CRT 9.0 does a malloc() and then CRT 10.0 does the free(), you're almost certainly going to corrupt something because they are not compatible.

I suspect Mathworks is relying on people installing Python themselves so they don't have to redistribute it as part of MATLAB, which is totally fine, but you have to be prepared to deal with this situation. If they make their own build, they need to distribute it themselves (easy) and explain to people why numpy doesn't work anymore unless you use their special build of numpy too (ie. because it uses a different CRT).

Like I said initially, we would probably accept a patch for uuid.py to skip the CRT scan on Windows, and similar changes like that where appropriate. If you need to be able to load the DLL yourself, you either need to carefully consider how the functions you call may interact with other implementations/versions that may be loaded, or set up the manifest so you can load msvcr90.dll.