Ok, I've come up with a compromise here. There seems to be quite a bit of opposition to calling this a "runtime context," so I've kept the phrase "thread state," but I've changed the glossary definitions to mostly fit Eric's suggestions. At the bottom of the "attached thread state" definition, I've added a note about free-threading:

In free-threaded builds of Python, threads can concurrently hold an attached thread state, allowing for true parallelism of the bytecode interpreter.

I think this is an important part to emphasize--from the user's perspective, all free-threading really does is allow for multiple active thread states at a time, and that gives a good intuitive sense of why things like PyGILState_Ensure are still needed on FT builds. If there's any other places we should try to mention this, let me know.

Regarding this part:

current does not imply attached, but attached does implies current

I decided just to drop any mention of the "current thread-local state pointer" and just replaced everything with being either "attached" or not. It's probably better to keep how we expose thread states out of the documentation.

So, with all that in mind: I didn't expect the Spanish Inquisition

Nobody expects the Spanish Inquisition!

@ericsnowcurrently: please review the changes made to this pull request.

Oh, I missed the change request (is it just me or were these more prominent not that long ago?)

@ericsnowcurrently, do you want to block this iteration?

No real objections; I defer to you, Victor and Alyssa.

I already approved the PR :-)

Thanks! Let's build on this :)