Speaking as a pip maintainer I definitely would want a PEP if the design required imposing a priority order on indexes. Moreover, now that uv exists, “installer behaviour” is very much something that can only be relied on if there’s a PEP standardising it. (That always was the case, but people used to assume that if pip did something, that was good enough in spite of us reminding them that it wasn’t 
).
Speaking as a potential PEP delegate, if the PEP doesn’t specify the behaviour precisely enough for it to be implemented in pip without “hidden” implications like this, then the PEP isn’t sufficiently detailed, and I’d want that fixed.
To put what I said above another way, any design that involves having two different index URLs serve the same filename with different content, is extremely unlikely to get accepted. This would break a lot of code, including caching algorithms based on the wheel filename.
Basically, don’t assume that adding index priority to pip will be acceptable. The issues you linked to give some sense of how complex the whole matter is, and either you need to address all of that complexity (good luck!) or you’re going to add a special case that implements index priority in just one part of pip, and that’s going to be a maintenance nightmare.
In all honesty, if you want to go down this route, I’d want a separate PEP, entitled something like “Selecting Python package files across multiple sources”, which defined standard behaviour required of all installers and consumers of data from package indexes. It would need to integrate with PEP 708[1] as well, which is how we currently handle this issue. The variant wheel PEP would then depend on the guarantees provided by that other PEP.
which is (provisionally) accepted, but still hasn’t been implemented in the ecosystem - so there’s that, as well
↩︎