Why doesn't everyone just move toward a standard where all executables can be a ZIP file with some glue, and every execution results in the OS unzipping into a

Why doesn't everyone just move toward a standard where all executables can be a ZIP file with some glue, and every execution results in the OS unzipping into a cache folder matching the hash of the zip? The OS could also scan a set of directories for executables and pre-extract all of them, and then you could run a command which reverse-matches hashes to executables, so that for example, if you have an app and it's built against a dependency with a specific hash, it can find that hash on the system regardless of the file name. So you could have executables just sprawled out everywhere on disk, but executing one program would only result in the exact dependencies being loaded, no conflicts. At the same time, you could reference an executable name instead of a hash to use the latest installed version. So you could run an app with "as-originally-compiled-dependencies" or "latest-installed-dependencies". And if you supported recursively resolving zips inside other zips, you could deliver an entire app stack with one file. As far as avoiding a cache directory, it should be possible to mmap() each specific file in the [uncompressed] zip into memory, have a filesystem driver translate a zip index into a virtual filesystem, and then reading from the virtual filesystem would just read from those mmap()ed sections of memory. That may be stupid, though, so perhaps the zip file can just be a delivery mechanism and a flat-file standard along with kernel modules can provide the rest of the utility?