Speaking with my PEP delegate hat on, I’d like to suggest some caution here. We’re getting way ahead of ourselves discussing details of symlink support, and especially of how installers will handle the transition, when there’s not even a proposal for Wheel 2.0 yet.
Also, the whole split between PEP 777 and PEP 778 seems misguided to me. We don’t agree new versions of standards independently of functionality. Rather, new functionality gets proposed, and if it needs a new version of the standard, the introduction of that new version is part of the proposal for the new functionality.
If there’s multiple proposals, they will each need their own version bump - or they are going to have to be presented and approved as a group, which will significantly complicate the whole process.
It may be that PEP 777 will make all this clear, and include a plan for incrementally adding functionality that makes my concerns unfounded. But honestly, I doubt it. Whatever happens, though, we should either be working on PEP 777 first, or this PEP should include the bump to wheel 2.0, and other PEPs adding functionaliy to the wheel format will need to define their own version bump.
(To be clear, I think one of the big problems here is that wheel format versioning needs a rethink - as the “what will pip do with version 2.0 wheels” subthread established, a major version bump is very disruptive, and yet no-one has come up with a plausible example of something that would be a minor version bump. So unless we come up with something better, every bit of new functionality is hugely disruptive, and we end up trying to make “kitchen sink” changes bundling all the functionality improvements that are currently blocked on a version bump into one change. And these current PEPs seem to be doing just that, although they are trying to hide that fact by splitting things into multiple PEPs - but if the PEPs can’t be implemented independently, they remain one change in practice).