Your post advocates a

( ) system
( ) language
( ) app store
( ) curl | bash

approach to package management. Your idea will not work. Here is why it won't work.

( ) It is not suitable for desktop software
( ) It is not suitable for server software
( ) It is not suitable for frontend software
( ) It is not suitable for embedded software
( ) It can only be used on the most popular platforms
( ) Too flexible
( ) Too inflexible
( ) Requires people to manually do dependency resolution
( ) It is defenseless against typosquatting
( ) Requires immediate total cooperation from everybody at once
( ) Many users cannot afford to host package infrastructure
( ) Many developers cannot afford to pay for signing certificates
( ) Many users cannot afford to pay for your expensive hardware
( ) Users will not put up with it
( ) System administrators will not put up with it
( ) Maintainers will not put up with it
( ) Developers will not put up with it
( ) Google will not put up with it
( ) Microsoft will not put up with it
( ) Apple will not put up with it
( ) Black Hats will love it
( ) $YOUR_LEAST_FAVORITE_DISTRO will mess it up
( ) $YOUR_LEAST_FAVORITE_VENDOR will mess it up

Specifically, your plan fails to account for

( ) Existing package managers doing things differently
( ) People failing to commit changes to lockfiles
( ) People installing software without using your package manager
( ) People who need their existing package manager to know about your dependency
( ) Man-in-the-middle attacks
( ) Uninstalling software
( ) Config files
( ) Asshats
( ) Every dependency needing a slightly different version of the same library
( ) General reluctance to accept weird new forms of software delivery
( ) Corporate firewalls blocking SSH
( ) Corporate firewalls blocking HTTPS
( ) Corporate firewalls blocking BitTorrent
( ) Corporate policies prohibiting cryptocurrency mining
( ) Cloud provider policies prohibiting cryptocurrency mining
( ) Not all devices have an Internet connection
( ) A maintainer deciding to delete all of their published packages
( ) A maintainer being paid off to distribute malware
( ) A package being approved despite hiding malware
( ) Install scripts executing arbitrary code
( ) Security rules that are so broad as to require granting permission to do anything
( ) Security rules that are so restrictive as to require hours to understand
( ) Nobody knows how to use Git correctly
( ) Nobody knows how to use GPG correctly
( ) Nobody knows how to use OpenSSL correctly
( ) Nobody knows how to use Autotools correctly
( ) Nobody knows how to write M4 correctly
( ) Nobody knows how to write RPM specfiles correctly
( ) Nobody knows how to write Debian control files correctly
( ) Nobody knows how to write Makefiles correctly
( ) Nobody knows how to write shell scripts correctly
( ) Nobody knows how to parse YAML correctly
( ) The central authority's servers will go down
( ) Developers can't wait for an opaque centralized approval process every time
they need to run new code
( ) QA testers can't wait for an opaque centralized approval process every time
they need to run new code
( ) End users can't wait for an opaque centralized approval process every time
they need a security fix
( ) Distros don't deal well with multiple versions of a piece of software at once
( ) People need to be able to get security fixes without other behavior changing
( ) Security scanners
( ) License compliance scanners
( ) Privacy concerns about phoning home on every update
( ) It's not feasible to force people to upgrade everything at once
( ) People trying to upgrade everything at once
( ) People who need to install software but don't have root
( ) GitHub rate-limits

and the following philosophical objections may also apply:

( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) The idea is mathematically sound, but NP-complete
( ) Why should we have to trust you and your servers?
( ) Not everyone uses or likes semantic versioning
( ) At least one upstream will use a versioning scheme incompatible with
yours
( ) "Immutable" doesn't mean what you think it means
( ) Nobody can agree on what a breaking change is
( ) It is impossible to automatically verify that no breaking changes have
occurred without both parsing natural language documentation and solving
the Halting Problem
( ) Even then, someone will still find a use case under which the old version
worked and the new one didn't
( ) This idea attempts to use cryptography to solve a social problem
( ) This idea attempts to use a type system to solve a social problem
( ) People should be allowed to decide what software they run on their own devices
( ) It should be possible to download and run software without building its entire
toolchain from scratch every time
( ) It should be possible to distribute software without publishing its source
code to the public
( ) The idea is too beholden to backward compatibility to make forward progress
( ) The idea tries to force forward progress without any accommodation for backward
compatibility
( ) Someone will need to make a breaking change eventually
( ) Software will have vulnerabilities even if everyone does that
( ) Unpaid volunteers will quickly lose patience with doing that
( ) Incompatibility with free/open source software licenses
( ) Incompatibility with proprietary software licenses
( ) People are bad at naming things
( ) You've picked a bad abstraction that glosses over platform differences
( ) This is indistinguishable from how malware works

Furthermore, this is what I think about you:

( ) Shine on, you dreamer of impossible dreams
( ) This is a stupid idea, and you're a stupid person for suggesting it
( ) You deserve to be a maintainer in $YOUR_LEAST_FAVORITE_DISTRO
( ) You deserve to have hundreds of uninvolved people from Hacker News, Reddit,
Twitter, Tumblr, and Slashdot all pile onto a controversial bug in your project's
bug tracker to "helpfully" "share their opinions"