Disagree completely. OS package managers are one of the biggest sources of problems.

Basically, once you have an OS level package manager, you have issues of versioning and ABI. You have people writing to the lowest common denominator - see for example being limited to the compiler and libraries available on an old Red Hat version. This need to maintain ABI compatibility has been one of the hugest issues with evolving C++.

The OS package manager ends up being a Procrustean bed forcing everything into its mold whether or not it actually fits.

Also, this doesn't even have the issue of multiple operating systems and even distros which have different package managers.

Rust and Go having their own package managers has helped greatly with real world usage and evolution.

This is a weird opinion, but I think that the OS package manager's complexity is largely owing to the unix directory structure which it just dumps all binaries in /bin, all configuration files in /etc, all libraries in /lib. It comes from a time where everything on the OS was developed by the same group of people.

By dumping all the same file types in massive top-level directories, you need a separate program (the package manager) to keep track of which files belong to which packages and dealing with their versions and ABI and stuff. Each package represents code developed by a specific group with a certain model of the system's interoperability.

GoboLinux has an interesting play on the problem by changing the directory structure so that the filesystem does most of the heavy lifting.