Launching python subprocess has different behavior depending on launcher

I'm attempting to launch Python 2.5 from Python 2.6. The reason for this is a compiled library I'm trying to use (GDAL) isn't supported for the version of Python distributed with another program (ArcGIS).

Here's what I'm attempting to do. The main.py file in Python 2.6:

import subprocess
p = subprocess.Popen(['C:\OSGeo4W\gdal_python_exec.bat', 'X:\\local\\import_tests.py'])

gdal_python_exec.bat is a windows batch script that fires up the 2.5 version of Python I want while also setting up some environment variables:

@echo off
set OSGEO4W_ROOT=C:\OSGeo4W
PATH=%OSGEO4W_ROOT%\bin;%PATH%
for %%f in (%OSGEO4W_ROOT%\etc\ini\*.bat) do call %%f
@echo on

@C:\OSGeo4W\bin\python.exe %1

import_tests.py tries to import gdal:

try:
    from osgeo import gdal
    raw_input('Imported! (Press enter)')
except Exception, e:
    print(e)
    raw_input('Failed! (Press enter)')

When I run main.py at a DOS command line as python.exe main.py (that's Arc's 2.6 version of python), things work fine. However, if I take the same script and add it as a 'toolbox' inside the main application and launch it from there, I get a "DLL not found" for the GDAL lib inside the import_tests.py file!

How can this happen when subprocess is the module that's launching a different Python interpreter? Any ideas on what could be happening?

Edit: I can verify that the os.environ['PATH'] variables are the same in both calls.

Edit2: The C:\Program Files\ArcGIS...\Bin directory contained a dll that wasn't compatible with my python bindings. Windows searched the cwd first and attempted to load that dll, failed, then reported a "dll not found" error.

Regardless of whether PATH is correct, a simple test would be to change to a different arbitrary directory and do python.exe C:\full\path\to\main.py. If that reproduces the problem then you know it's some sort of path problem.

Check sys.path, I'll bet that's where the difference is. If that's the case, you probably need to alter the way you make your Python code and libraries are accessible from python.exe, either using the site module or using something else like zc.buildout/zc.recipe.egg's support for generating console_scripts with the correct sys.path baked in.

It appears from comments posted elsewhere that