Note for readers: the ABI marker discussion between Steve and I will likely only make sense if you’ve read https://github.com/python/peps/pull/1190/files, which changes the ABI management proposal to actively encourage the publication of binary wheels during the pre-freeze phase.
Say we end up having three releases that include ABI breaks: X.Y.0a1, X.Y.0a4, X.Y.0a7. The X.Y.0a7 ABI is then the ABI that carries through all the subsequent beta releases and into X.Y.0rc1.
Forcing everyone to rebuild the world every time there’s an alpha release in the rolling release stream would almost certainly lead to publishers deciding supporting the rolling releases was more trouble than it was worth, so we want to allow modules built against X.Y.0a1 to be loaded against X.Y.0a7, as they’re probably going to be compatible. If a module does break though, but works after recompiling, then users of the rolling stream need to ask the affected project to push a new build against the latest alpha ABI, rather than bringing it up with us.
Once we hit X.Y.0rc1 though, we want any binaries that were built against X.Y.0a1 and X.Y.0a4 to be completely gone from the end user experience. It would be nice to be able to keep the builds against X.Y.0a7 and any subsequent beta releases (since it turned out those actually were built against the post-freeze ABI, even if we didn’t know that at the time), but losing them isn’t any worse than the status quo. So the pre-freeze flag is “the simplest thing that could possibly work” - it’s just a new ABI flag, and we already have the tools available to deal with those.
A cleverer scheme that was able to retroactively accept everything built against the last alpha or later would likely be possible, but I don’t think it’s necessary, and I don’t think starting out with a simple pre-release flag would rule out migrating to a cleverer scheme later.