However if you look at the design goals, most of them have been implemented, although there is not yet wide usage.
The best way to try this out in a runable desktop OS is probably Silverblue.
https://silverblue.fedoraproject.org/
> We want a unified scheme, how we can install and update OS images, user apps, runtimes and frameworks.
The storage backend for this is OSTree, using HTTP as the transport; it's analogous to Git for binary files and does not require special filesystem features, only hardlinks.
https://ostree.readthedocs.io/en/latest/
> We want a unified scheme how you can relatively freely mix OS images, apps, runtimes and frameworks on the same system.
Flatpak provides the abstraction layer for this; the base OS can be anything and the applications use only libraries from a Flatpak runtime; by default, Flatpak uses OSTree to store applications.
Snap is similar, although it requires AppArmor, so can't run on many popular distros, and I think there's only one runtime that you're required to use, so no "mix and match".
Docker is similar, although it can't handle desktop applications in a sensible manner (no sandbox).
> We want a fully trusted system, where cryptographic verification of all executed code can be done, all the way to the firmware, as standard feature of the system.
There are several points here:
* firmware/pre-boot: [Edit: TPM can be used to verify this, but it's not set up that way by default; Windows 10 Bitlocker can rely on TPM for this]
* bootloader: UEFI Secure Boot handles this
* kernel/initramfs: I'm afraid this isn't typically verified currently, see https://mjg59.dreamwidth.org/54203.html
* base OS and Flatpak: OSTree can require GPG signatures for installation; to check the files at runtime, you'd need an additional layer such as dm-verity.
> We want to allow app vendors to write their programs against very specific frameworks, under the knowledge that they will end up being executed with the exact same set of libraries chosen.
FlatPak SDKs provide this.
Snap has an SDK as well, although note the singular, Snap is exclusively controlled by one company.
> We want to allow parallel installation of multiple OSes and versions of them, multiple runtimes in multiple versions, as well as multiple frameworks in multiple versions. And of course, multiple apps in multiple versions.
Flatpak can do multiple framework versions by default, and multiple application versions with command line flags.
Multiple different OSes hasn't happened yet, probably you'd want at least one non-experimental OS first...
> We want everything double buffered (or actually n-fold buffered), to ensure we can reliably update/rollback versions, in particular to safely do automatic updates.
OSTree does this.
> We want a system where updating a runtime, OS, framework, or OS container is as simple as adding in a new snapshot and restarting the runtime/OS/framework/OS container.
OSTree/Flatpak again.
> We want a system where we can easily instantiate a number of OS instances from a single vendor tree, with zero difference for doing this on order to be able to boot it on bare metal/VM or as a container.
No idea if this exists anywhere yet.
> We want to enable Linux to have an open scheme that people can use to build app markets and similar schemes, not restricted to a specific vendor.
Flatpak/FlatHub solve this; Snap does not because it's exclusively controlled by one vendor.