Your comment is a beautiful demonstration of the problem -- a lack of understanding of the existing tool drives a desire for a new, different tool.
There is absolutely nothing about apt or dpkg that are os specific other than they require a posix-like environment. The same goes for rpm and yum. And pacman.
At the end of the day, these package managers all do the following:
1) describe the dependency relationships of packaged software
2) describe where to extract files
3) describe any actions that need to be taken prior to or after extracting files
There's nothing stopping you from installing .debs with dpkg on an RedHat system nor .rpms with rpm on a Debian system aside from conflicts when both package managers try to put files in the same place.
This same conflict occurs when language package managers come into the picture, because newsflash: someone else has been working on the same fucking problem for decades, and somewhere between just ignoring their work, and actively hampering it.
Can you give an example of a project, maybe a programming language ecosystem, that unifies some sort of publish-once, access-anywhere package system that uses those tools and works across Linux, Windows, and macOS?
I don't understand what that would look like in practice. Tools like Homebrew and MacPorts don't even do what you are asserting is the obvious, trivial way to do it. And I have a feeling it isn't just because my microbrain doesn't get it.
For example, I don't see how your post pitches something different than what I used to have to do with C/C++ deps and CMake back in the day, and those were not the hey days of dep management.
Also, enough with the animosity. When you find yourself registering a new account because you want to sneak in some venom when talking about software dep management on an internet message board, what are you doing?
Gentoo prefix can run on a wide variety of operating systems and distributions. It needs a few updates to work around the recent changes in macos permissioning, but if it can find a familiar shell it will more or less work as expected.
I think part of the above comment is expressing frustration about the fact that part of the reason for the lack of wide portability of these programs is precisely because people say "oh they can't do x" or "this is operating system specific" and taking it as axiomatic rather than realizing that with a bit of engineering time and effort they can be extended to work on other systems. This especially since there is pretty much no language that is used entirely by itself without dependencies on another at some point in time. If your language has a ffi, then you need a real package manager to accompany it.
So, I have a useful library that I want to share with the world. I do what, exactly, so that other people across platforms can use it?