We encountered the same issue when upgrading our application's JRE from 1.5 to 1.6.
We use a kind of grid, which has engines written in C, which uses an embedded JAVA JVM, which loads C dll. One of these uses python.

Here is what happens:
1. C executable launches an embedded JVM, which loads its required dlls.
2. JVM sets PYTHONHOME environment variable through windows kernel API: SetEnvironmentVariable
3. JVM loads our C dlls to start computations
3. One of the dlls invokes Py_InitializeEx, which must read PYTHONHOME in some way (C runtime getenv?). Python 2.5 here, with MSVCR71.dll loaded.
4. Computations are done with invoked python

With JRE 1.5, Python is able to get correct PYTHONHOME, and can do "import os" in our script.

With JRE 1.6, this is not the case, as JRE 1.6 loads MSVCR71.dll @ step 1. JRE 1.5 did not.

As stated in the previous comments, and from my understanding, in Windows there is the "Process Environment Variables Space" and possibly several "C Runtime Environment Variables Space".
The first time a C runtime dll is loaded, it copies the Process Env Var into its own buffer.

Our JRE 1.6 loads msvcr71.dll (C runtime), and so copies env var @ step 1.
It happens before we set PYTHONHOME with JAVA @ step 2.

To correct this, we had to use the Py_SetPythonHome function before calling Py_PyInit to set PYTHONHOME ourselves
This way, Python executes our code fine when we use JRE 1.6.

But this is because we do not call any getenv functionality within python at the moment, but it could happen in the future...

As stated by eudoxos, the safest solution for windows is to use GetEnvironmentVariable (win32 kernel API).

Is there any schedule for a fix for this problem?

Thanks for you time and answer.

Regards.