All future optimizations upon resuming JIT development will be reviewed with free-threading compatibility and performance impact required before merge. Optimizations that rely solely on the GIL build and break on the free-threaded build will be rejected.
It’s not only an issue of the free-threading runtime mode, but it’s going to be more intensified by free-threading. If the JIT compiler is expected to move memory reads/writes around (or eliminate redundant reads, move a read out of loop, …), which is a common and important optimization performed by any decent compiler, then Python needs some kind of memory model. Moreover, the memory reordering done by modern CPUs may already be an issue - the memory barriers included in within free-threaded refcounting probably help there, but one of the aims of the JIT optimizations will be eliminating the refcounting.
“Memory model” may seem like a big thing, but many programming languages have gotten a long way with pragmatic informal model along the lines of “use some annotation or language construct to prevent moving reads/writes around, otherwise anything can happen”. The important thing IMO is to clearly state that users should not rely on any ordering of concurrent reads/writes of plain memory locations and should use some abstraction provided by stdlib (recognized and intrinsified by the JIT - this can be easily polyfilled in older Python versions) or a language construct. 99.9% of the code doesn’t need to care and gets the benefit of advanced JIT optimizations. The 0.1% (or hopefully even less) of the code that performs unprotected concurrent memory accesses is inherently already doing complex concurrent programming, and the author should know very well what they are doing - ideally this kind of code would be found only in low level concurrency libraries/frameworks.
My concern is that specifying Python memory accesses as sequentially consistent could create a long-term constraint similar to exposing implementation details through the C API. These kinds of decisions may seem reasonable at the time, but by the time their drawbacks become apparent, it may be already too late.
Related discussion: What is the Long-Term Vision for a Parallel Python Programming Model?