Depends on what you want from a package manager.

Fast & simple? APK or pacman.

Here’s a script that sources your package definition script and creates a tarball and here’s another program that can unpack such tarballs into your system and keeps track of what file belongs to what package.
Put a bit of online repo complexity on top and that’s basically all these are.

I personally prefer pacman because it’s fast enough and the cli syntax is so awesome (-Syu pkgname is the same as 4 separate rather lengthy apt commands) but apk is even faster in my experience and works incredibly well for lightweight systems.

Complex but incredibly powerful? Nix and Guix

If you’ve never used them, they are nothing like what you’re used to. Doing them justice in explaining either requires something approaching a 280-page PHD thesis or a sentence full of hyper technical terms which require a PHD to understand.

They are very complex. Great effort has gone into these to make their ecosystems accessible to mere mortals though.
By making sensible abstractions on every level, they have gotten to the point where they can even be used similar to regular package managers (managing packages a single environment has access to imperatively) which will give you some of the benefits.
Using them to their true potential needs rethinking of how you manage software entirely though (not just software itself but also software configuration).

Nix uses its own specially crafted functional expression language while Guix is built on Guile (Scheme/Lisp) but they’re both implementations of the same ideas.
Nix has a larger community and is a lot more mature (more packages, wider support etc.) because of that but Guix has a better UI (Nix’ CLI tools are pretty scattered) and tries to bring this new way of thinking about software into more parts of your system like the init system.
Oh and Guix is a GNU project, so non-free software is not supported very well :/.

I’d highly recommend you to check out the new and improved NixOS homepage to get an idea of the cool things you can do with Nix and, to a lesser extent, Guix.

You can also install these beside your Linux system if you want to experiment. Because of the way they work, they are completely self-contained and don’t touch your actual system in any meaningful way. Nix can also be used on MacOS.

I’m very fond of Guix for a few reasons:

• functional package management. Every package in the Guix store is in its own isolated directory (identified by the hash of that package + its dependencies) and every package knows where its dependencies are in the store, so you can have packages that depend on conflicting versions of libraries, for example.
• transactional system upgrades, and ability to roll-back to a previous version of the system if an upgrade goes wrong somehow
• per-user package management (each user has their own set of packages that doesn’t require root to manage)
• packages/repositories (“channels”) are declared in a programming language (Scheme; not my choice of language but a language nonetheless) and version-controlled as git repos
• packages are built from source by default but can also be available as pre-built binaries (“substitutes” in Guix lingo) if a trusted CI server has them available. I think this is the “best of both worlds” of a binary and source based package manager (this does come with an annoying pain-point, where you don’t really know if you’re going to get pre-built substitutes when you run guix upgrade, especially as packages that are less trivial to build also end up more likely to not be available from the CI server)
• being able to install a package from a different source (e.g. a tarball, git branch/commit) (guix install --with-source, --with-branch, -with-commit, etc)
• the default repository adheres to GNU’s free distro guidelines, which is always (for me) a plus. That being said, there’s maybe a dozen user-created channels with non-free kernels and non-free apps if that’s your thing too.

Package Management section of Guix manual

Now, one thing I don’t like about Guix is that its unconventional approach to package management often makes building more complicated packages a challenge, because those packages have to be patched to behave properly in the Guix environment.