It's important to resolve changes to the package environment as a whole. Pip doesn't really do this, and as of a few years ago didn't even resolve multiple CLI-specified packages together, and this causes major compatibility and consistency issues.
Doing this correctly can be difficult to get fast, but performance does matter. Resolving Conda environments adds way too much time to CI jobs. The Pkg.jl resolver is pretty great and we never have to wait for resolution. It's my understanding that this was a non-trivial technical problem that went through a few implementation iterations.
Explainability on failure to resolve is a really useful tool that becomes more difficult the more features you add. Pkg.jl has struggled with this in some cases where it hides certain version restrictions (e.g. "by explicit requirement" is rough when your project hasn't set that particular requirement). Lots of people have spent lots of time trying to identify incompatibilities over the years, and we've had to rely on people developing arcane knowledge to interpret resolution failures.
Immutable, cached packages is important for avoiding spending a lot of time downloading. It's very important to completely distinguish different versions/configurations though, i.e. you don't want a configuration setting that affects which code gets put at `~/mypkg/packages/<pkg-version-id>`.
The package source should be reliable/redundant. People will install packages in the course of normal work (automated updates, testing, etc.) and will need an always-on package manager. GitHub has proven not to be reliable enough.
At the same time, an offline mode should be available.
Getting installation configuration options right can be a big value add. I love cargo's feature flag implementation, and even Python now has "extras".
Every package manager eventually regrets not adding a "yank" feature.
Enterprise users will always eventually want to see multiple sources (private and public).
I appreciate when package managers consider the audience for their output and don't output line-by-line progress meters when running in a non-interactive environment.
Querying the package dependency tree is really useful! Both dependants and dependencies, flat and recursive. Even better if there's a library to do this that you can script and experiment with.