Strong +1 on this. The main reason we created PEP 517 was to allow multiple implementations. We now have a number of build backends. Having multiple frontends is also hugely important to the health of the community - as @FFY00 has already noted by pointing out that pip isn’t the right fit for distributions. Having multiple wheel installers, far from being “duplication of effort”, is actually the whole intention behind the packaging standards approach, and I’m disappointed if people have missed that message and are still hoping for “one true tool”.
-1 on this. PEP 517 has been around for 5 years now, and I don’t think we should need to treat it as a “second class citizen” by this point. I’m not saying that we should actively push people away from setuptools, but I see no reason to stop any project from using an alternative backend if it suits their needs. If Linux distributions still aren’t in a position to handle that, then I have sympathy, but I’m not inclined to hold the ecosystem back until the distros address that problem. Distros can ask individual packages, if they so wish, but I don’t think the “Python packaging community” or the PyPA should add their weight to such a message.