No, those wouldn't change at all. However, after thinking about it further, I'm leaning back towards the option of an EnsureEx/ReleaseEx pair that allows the previous interpreter to be reported and restored along with the GIL state. I'd also like to make the state an opaque structure that isn't exposed in the limited API. Something along the lines of:

    typedef struct _gilinfo {
        PyGILState_STATE  lock_state;
        PyInterpreter     *active;
    } PyGILState_INFO;

    int /* Allow returning an error code */
    PyGILState_EnsureEx(PyInterpreterState *target,
                        PyGILState_INFO    *prev);
                                        
    void
    PyGILState_ReleaseEx(PyGILState_INFO *prev);

This allows various issues related to implicitly creating thread states to be handled the same way they are now, where PyThreadState_New will create a persistent thread state, while PyGILState_EnsureEx will either use a preexisting thread state for the requested interpreter (if it exists), or implicitly create one. Implicitly created thread states would be destroyed by the corresponding call to ReleaseEx.

To make this work, I believe all that should be needed is for:

1. PyInterpreterState updated to include a per-interpreter TLS key
2. _PyGILState_NoteThreadState would update both the autoTLSkey entry and the per-interpreter key entry
3. PyGILState_EnsureEx added to support switching the autoTLSkey entry to point to a different thread state (creating it if needed)
4. PyGILState_Ensure updated to map to PyGILState_EnsureEx(NULL) and to extract the lock state from the info structure
5. PyGILState_Release updated to populate the info structure with the active interpreter and the passed in previous GIL state before calling PyGILState_ReleaseEx
5. PyThreadState_Delete and PyThreadState_DeleteCurrent updated to also clobber the per-interpreter TLS key entry

PyThreadState_New already calls _PyGILState_NoteThreadState implicitly, so Python created threads (and embedded threads with an explicitly created thread state) should do the right thing automatically.

Making the INFO struct an opaque token also means it can be expanded to cover any future needs that arise.