(Sorry for the delay!)

Is the need for a named section due to the fact that _PyRuntime is part of the "internal" C-API (hidden behind the Py_BUILD_CORE macro)?  I.E. would it help to build with Py_BUILD_CORE?


Regarding the GIL:

The plan for 3.9 is to have one GIL per interpreter, so the relevant struct would be PyInterpreterState (a part of the public C-API).  That would be accessible at runtime via the fields of _PyRuntime.interpreters.


Regarding what I said before about multiple runtimes per process:

Honestly, I've yet to see any use case that would justify providing multi-runtime support.  However, there are code-health benefits to keeping *all* runtime state out of static globals.  So eliminating the _PyRuntime static variable is still a realistic possibility (for 3.9 or maybe later).

If that happens then there would have to be a new embedding C-API oriented around (opaque) PyRuntimestate pointers.  See PEP 432 and 587 for ongoing work to improve the embedding experience (for runtime initialization), including what the successors to Py_Initialize() look like.