It seems to me that this discussion is being undermined by not acknowledging the many use cases up front. There is no rationale because there are too many tacit rationales.
I honestly, really, cannot imagine what those are. Explicit is better than implicit.
Nevertheless, the many use cases are related at some level and would benefit from some form of lowest-common-denominator support in the standard library. As an example, IF I wanted to use a library to support multi-version packages or one to ensure I had all the dependencies, I would need to know what versions of things were currently installed.
How would you install multiple versions in the first place? Python supports no such thing, at least not without setting PYTHONPATH, or otherwise changing sys.path.
My personal use case is for multi-version packages. I deploy many small scripts (not applications) that use an evolving set of base libraries. I don't want the older scripts to hold me back from pushing forward with the base libraries, so I peg the scripts to their respective major versions as I release them.
I could not have imagined that as a use case. I never install multiple versions of the same thing on the same system, except for Python itself. I also try to avoid using evolving libraries as much as possible, and quickly abandon libraries if they change in an incompatible manner across releases, at least if porting becomes too much of a burden. Notice that this use case isn't listed in the PEP, and I cannot see how the PEP can help providing that functionality. Regards, Martin