I'm unsure if you are understanding what I'm doing so here is the 
story...

I stepped through Py_Initialize and this function takes the main 
interpreter and it's initial thread state and makes that the GIL thread 
state.

The following code in Py_Initialize hijacks the main interpreter and 
thread state for GIL use...

/* auto-thread-state API, if available */
#ifdef WITH_THREAD
    _PyGILState_Init(interp, tstate);
#endif /* WITH_THREAD */

WITH_THREAD is defined since I'm using multithreading in my application.

So now if you create thread states from the main interpeter and use the 
PyEval_Acquire/Release and PyThreadState_Swap you will get the 
assertion when compiled with the DEBUG option. If you use the 
PyGILState_Ensure and PyGILState_Release functions you don't. 

What I'm doing is that I have a Windows application with embedded 
python.  The application spawns multiple threads each running a python 
script.  Each application thread has its own unique PyThreadState 
created from the main interpreter because I wanted all the modules 
loaded only once for resource conservation purposes (thus use only one 
interpreter). I used PyEval_Acquire/Release and PyThreadState_Swap to 
handle swapping in each application thread's thread state when each one 
uses the python API.  This worked great in RELEASE compilation but in 
DEBUG it asserted.  Now that I use the GIL functions it works well and 
not only that, I removed the code I had put in myself to handle python 
callback's into the application and avoiding deadlocks by calling 
PyEval_Acquire onto itself (since it uses mutexes which doesn't do 
reference counting so it could deadlock waiting on itself to complete)