Of the listed benefits, I think the most interesting one is the fact it would enable pip's wheel cache by default for all installations, rather than relying on projects publishing pre-built wheel files to PyPI.

However, actually doing this would run counter to the design goal of declaring even the current installation of setuptools to be an implementation details that shouldn't be relied on: https://www.python.org/dev/peps/pep-0453/#automatic-installation-of-setuptools

This relates to the fact that in PyPA, we're aiming to reach a point where we treat setuptools & wheel as *optional* dependencies of pip, such that it's straightforward to create environments that only support installation of wheel files created elsewhere, and don't allow installations directly from source archives at all.

The recently approved PEP 517 represented a notable step in that direction.

That said, we're also discussing the possibility of changing the way we provide distutils to be dependent on automatic installation of setuptools [1], and if we *did* decide to go down that path, then I think it would be appropriate to consider installing both setuptools *and* wheel as part of an "ensuresetuptools" module, rather than just installing setuptools.

Accordingly, while I *am* going to close this (and the related PR), I'm going to close it as "postponed" rather than "rejected" - it isn't that we're definitely never going to do this, it's that there are other long term design considerations involved, and doing this prematurely has the potential to lock us out of design paths that we'd like to keep open.

[1] https://mail.python.org/pipermail/distutils-sig/2017-September/031540.html