A few points to consider, which are reflected in my other comments:

• current does not imply attached, but attached does implies current
• the glossary probably isn't the best place for C-API details
• "runtime context" or "execution context" might be a clearer term for users than "thread state"

The only tricky part is that we already talk about "contexts" relative to asyncio.

I'll commit the suggestions tomorrow when I'm available to do a full find-and-replace so I don't blow up CI in the meantime.

For the per-thread thread state pointer (what a mouthful!), I'm happy with something like "runtime context," because there was no prior term for it, but I think we do want to keep the term "thread state." Thread states are documented, and users like to read the source code to understand some C functions--seeing _PyThreadState_GET and "thread state" in the documentation makes things more clear. That, and "context" doesn't convey the fact that it's a thread-local too well, which is important.

the glossary probably isn't the best place for C-API details

Hmm, we do have "borrowed reference" and "strong reference" in there; where else should "thread state" point to?

"runtime context" or "execution context" might be a clearer term for users than "thread state"

I like "thread state" :-)

+1 for sticking with thread state.

Between contextvars and context managers, and just the general idea of "context of execution", "context" is seriously overloaded already.

"thread state" isn't completely unambiguous (it could theoretically take on the holistic meaning of "all state associated with the current thread, including the execution stack and all thread local variables"), but the context(!) of use should help avoid that misinterpretation.

"Runtime context" in particular is problematic, since the execution model is set up with the hierarchy of:

• there is one runtime, which may be serially finalized and reinitialized, but you can never have more than one at a time
• the runtime will host at least one interpreter, but may host more
• each interpreter will have at least one thread state, but may have more
• for an OS thread to execute Python code, it must be associated with a Python thread state (which also indirectly determines which interpreter it is associated with)