Great research on Python literature. The implicit memory model is really “whatever CPython happened to have implemented at the time PEP 703 was written”. By promising “per-object locking aims for similar protections as the GIL” it implies a sequential memory model with atomic behavior for builtin objects. Only when free-threading gains widespread use can we see how well the promise really holds up.
I don’t think this would necessarily be the case, but it does seem that the various projects to enhance Python (free-threading, JIT, etc.) are sometimes not really tuned to the same wavelength. And here goes the classic open-source project management problem: “Organization A has successfully forked a software to implement feature A for their own use cases” and “Organization B has successfully forked a software to implement feature B for their own use cases” does not mean that we can make the mainline implement features A and B simultaneously without hassle. This is especially the case in Python as enhancements are often driven by enterprise- and domain-particular needs. The current proposal focuses on enabling JIT specialization (for which __shared__ state is useful) but doesn’t go as far as writing machine-specific assembly on-the-fly — in any case we still need to state what actually limits the future potential JIT from going so low-level. (In other words, write down why low-level JIT is a bad idea in Python.)