So for me, the first problem is the ordering of manylinux over linux (I see there’s a proposal for a “local” tag with the highest precedence, which fixes this problem). I can do tricks (and have done) with devpi to only whitelist certain packages to allow PyPI access, but there’s no distinction between wheel and sdist, which makes this somewhat painful (I could look at adding this as a feature to devpi, but then this means every PyPI caching tool need to implement something similar to achieve the same result).
The second is not every manylinux wheel is the same. People like Matthew Brett produce wheels that can be relied on, but some projects like tensorflow don’t, which increases the difficulty in debugging issues.
The third, and the one which really doesn’t have a workaround (beyond using local and being really careful), is some projects are inherently tied to some C library which has different, non-compatible build configurations (mpi4py is one example). Either you don’t compile with the library (e.g. h5py manylinux wheels do not depend on mpi4py for this reason), or you don’t distribute manylinux wheels. Being able to distribute manylinux wheels, with users able to opt out easily as needed, would seem to me to be a better option than having no wheels at all. A more advanced wheel metadata system could handle this, with some kind of tagging for different builds, but that breaks the assumption that the sdist/wheel relation is one to one for a given system.
In terms of maintainability, I suspect the only thing that would supersede this would be if there was a replacement for manylinux, as the other options I can think of (having a white/blacklist for packages and/or versions, adding additional options to pip) imply a higher level of complexity, with more issues for backwards and forwards compatibility (what settings should be used on a older pip, or a newer one). I did look at both trying to have packaging behave like pre-version 20 pip, and what would need to be done to implement PEP 600 in packaging (that would require a large amount of restructuring of the tag logic, which would likely need to be followed up changes in dependant packages - this is something that will need doing, but it doesn’t change things for the users this PEP targets), and this PEP is by far the simplest option I can think of, and I far as I can see, limited potential to break anything.