Convergence in the pip and conda worlds?

The tricky part will be the specification.

Conda, Nix, Debian and other closed infrastructures can do it by controlling the whole set of packages.

However Python packages are exposed to the wild world, where even "I need a C compiler" won't do, as there are many C compilers with different supported C versions, bugs, incompatible extensions, CLI interfaces, target platforms, ideas about ABI etc.

The "Authority" in "Python Packaging Authority" (PyPA) was originally meant as a joke, highlighting the lack of control that group is effectively able to exert. It's gotten increasing recognition from the core CPython developers and SC since then, but at the end of the day it's still only a self-identifying collective of people developing interrelated packaging solutions for a large segment of the Python packaging ecosystem, and the opinions expressed by folks who count themselves as a part of that collective don't necessarily the reflect those of the CPython project, even if they're probably some of the most visible and easiest opinions to find sometimes referred to by official CPython documentation. They have, for example, fairly recently (in Python lifetime terms) gotten Pip included directly in builds of the standard library shipped as part of CPython, which has increased the perception of official status for it.

A big part of why Pip is not viewed as "the official solution" to package installation is that PyPA has been striving to reinvent packaging tools so that they're based on published standards and specifications rather than a de facto "whatever this tool does is the standard" approach. This means even something as seemingly ubiquitous as Pip is supposed to just be one possible implementation of those standards, in order to allow for fair competition from anyone else who wants to develop an interoperable replacement. Officially blessing one solution is viewed by many as favoritism, making it very hard if not nearly impossible for any alternative to gain sufficient mind-share. The initial standards are being derived from what these tools do in order to not cause them to suddenly be non-compliant, but with the idea that as people want to implement sweeping new features or scope changes in the tools, they need to get them reflected in reviewed and agreed-upon published standards first.

Pip's maintainers see it as being responsible for meeting many of these use cases, but that doesn't mean the responsibility is placed on it by the CPython project. Rather, it's a scope the maintainers have chosen to give it, mostly in order to maintain backwards compatibility for users of earlier versions and predecessors like easy_install. They technically also have the "freedom to specialize" but they prefer not to exercise it, as that would leave many current users of its more general approach in the lurch.