Maybe there is a dep linking pattern I'm unfamiliar with then. Afaik static linking, or packaging dependencies along with the main binary and dynamic linking or depending on libraries present on the system (with or without the integrated feature of conditionally fetching those prior to install/execution of that main binary) are the two battle tested approaches to distribute apps. The first duplicates stuff, the second leads to compatibility surprises when developers think version 12.1.6 of one of the hundreds of dependencies is compatible but in fact only tested with 12.1.3 and assumes semver is always honored, then poor user user on that just one dependency update is left with an app that crashes.
If you don't mind explaining what splitting a package and de duplicating the download is, and how it prevents the issue I mention that would make me learn something :)
You're thinking of a system that's too clever for its own good. Go dumber.
Start with a setup where you're packaging all dependencies with your binary, dynamically linked.
Then, instead of a single zip file, put each dependency in its own zip, or even each file in its own zip. But each release is still a full set of specific files. You never refer to a dependency by name or version. That's too clever and fragile.
If two releases of two separate programs happen to share the same exact file, then you only need to download it once.
Words like "compatible" and "semver" have no meaning to this system, because you only deduplicate the exact same file. You save space if a developer reuses code correctly, but otherwise there are no visible side effects and no bugs.
If you don't mind explaining what splitting a package and de duplicating the download is, and how it prevents the issue I mention that would make me learn something :)