Thanks for taking a look! To answer your question, the need for the named section comes not from the API being being "internal", but because we need to access it at runtime from a tool running in a separate process.

We have augmented Crashpad (Google's crash reporter) tool, which inspects the memory of a crashing process to create/upload a report, to access each native thread's stack and reconstruct its Python stack frames. This allows us to quickly make sense of native crashes involving Python code. 

To do this, the tool needs to know where the Python runtime stores state within thread-local storage. This is actually the only reason we need to access `_PyRuntime`: it allows us to retrieve `autoTSSKey` for the process, which we can use to look up the `PyThreadState` for each underlying/native thread.

At the time, `_PyRuntime` seemed like a natural structure to expose and a named section a simple-enough way of doing so. We're certainly open to alternatives if you think there's a better way.

Given your plans for 3.9: I'm assuming `autoTSSKey` will remain the same per-process?