As I understand it, a new manylinux tag currently requires: a PEP, updates to pip, PyPI, and auditwheel, and new build images (not strictly required, but I’m not aware of any manylinux2010 images created without the build images). With this proposal, no PEP would be needed, nor updates to pip or PyPI, but it would still need a new profile in auditwheel and a new build image.
I have some concern that we’re solving the wrong problem. Auditwheel and especially the build images are the hard parts where maintainers are in short supply, and they would still need updating. A new PEP takes some effort, but the framework can be copy-pasted, the research into library versions would need to happen for auditwheel anyway, and having a PEP gives us a definitive description of what the tag means. The PyPI changes are trivial, just adding the new tags to a whitelist. The pip changes appear to have lingered in a PR for a few months on this occasion, but I don’t think there’s anything that should prevent them being merged quickly in general.
I don’t think ‘perennial manylinux’ would make anything worse, although perhaps there’s more room for confusion over what exactly a given tag means. But a big part of the stated motivation is how long it’s taken for manylinux2010 to be ready for use, and I’m not convinced that this will produce a significant improvement.