This feels feasible to me and is effectively close to what we currently see proposed via PEP 703. The difference being that in the early stages of letting the community experiment with a free threaded CPython, the PEP 703 version is an entirely different build of our runtime. The switch actually happens at CPython compilation time. Though there are ways that detail could be hidden behind a command line flag if we desire that interface.
I’d more or less expect work on specialization for to proceed in parallel without worrying if those benefits cannot yet be available in a free threaded build for a few of releases. Turning it mostly into an additional code maintenance and test matrix burden on the CPython core dev side to keep both our still-primary single threaded GIL based interpreter and the experimental free threaded build working.
I figure this is basically exactly what Mark claims not to want. Presumably due to the interim added build and maintenance complexity. But also seems like the most likely way to get to his “both” option 3 that I suspect we all magically wish would just happen.
I personally don’t think mark’s option list 1 / 2 / 3 reflects the actual slate of decisions to be made. But how to word that eludes me for now so I’ll save expressing that for later if it remains important.
We’ve got measurements for today’s impact: A vague ballpark number of 10% is accurate enough.
In the above scenario of doing both but ignoring most specialization in the free-threaded build, the divergence between the performance of the two builds for a single thread of execution will naturally increase over time in the above world. For development purposes it is reasonable to declare this as a known tradeoff.