I personally think it should be a Standards Track PEP. This PEP isn't documenting some detail like PEP 13 or some release schedule, but is instead proposing a rather major change to the interpreter which a lot of us will need to understand in order to support the code (and I do realize the entire area of "what requires a PEP and what doesn't" is very hazy).
Now, we've done similar things before (for example, the pattern matching implementation was a long-living branch), but the difference is that for pattern matching, the implementation followed the design, whereas for the changes to the bytecode interpreter that we're undertaking here, much of the architecture will be designed as the implementation proceeds, based on what we learn during the implementation.
Good point. We've also done long-living branching during Gilectomy which saved a lot of pain when it turned out not to be worth pursuing after all. Do you think this case is qualitatively different?
I think it's different -- the problems with the Gilectomy were pretty predictable (slower single-core perf due to way more locking calls), but it was not predictable whether Larry would be able to overcome them (I was rooting for him the whole time).
Here, we're looking at something where Mark has prototyped the proposed approach extensively (HoyPy, HotPy2), and the question is more whether Python 3.11 is going to be 15% faster or 50%. And some of the ideas have also been prototyped by the existing inline caches (some of the proposal is just to do more of those, and reducing the overhead by specializing opcodes), and further validated by Dino's work at Facebook/Instagram on Shadowcode (part of Cinder), which also specializes opcodes.