Since Petr Viktorin didn't add a formal reply to this, I'm going to do so instead. They emailed me some questions which this reply will have, along with my answers for them.
Q) - What do you mean by "core binary"? - If Python is embedded into another application, what happens to the state? - If the "main" interpreter is stopped and re-initialized (Py_FinalizeEx() Py_InitializeEx()), is the state recreated? A) - The term "core binary" refers to the binary file containing the compiled result of "pythoncore". - Nothing changes other than which binary is used to allocate the object (C global variable) - Generally speaking, Py_InitializeEx()/Py_FinalizeEx() denounces the lifetime of the core binary.
Q) So, if some Python code modifies sys.executable, the change should affect all interpreters in the process? A) No, Core State can not hold any Python heap allocated objects, also, virtually all Python first party types COPIES data into newly allocated memory.
Q) - What does "Branches from Core State" mean? - How will this state be available to the interpreter it's tied to? A) - This casually means that access to the Core State can be done with just a pointer to the active Interpreter State. Note: This can be accomplished via either a constant pointer inside the Interpreter State or (Global State only) with a global C variable. - See the above answer but from the Thread State & Interpreter State branching viewpoint. Note: The active Thread State assumes we're not changing how threading works in Python, BUT it's flexible enough for thread_local storage.
Q) How is this different from C "static" storage? A) Generally speaking, it's not different at all. This is the only State definition that can be dropped all together if widely unpopular. Note: But on the flip side, we will still require an initialization/finalization for extensions to implement (see Windows WSA/MySQL documentation)