Distributors entering Flatpakland

it isn't like flatpak and docker are using fundamentally different technology. Flatpak sandboxes are based on either bubblewrap or (I think) unprivileged namespaces if the kernel can support all required features, this means you don't need to be (effectively) root to run a flatpak.So it's not really a "remake" as much as "yet another use of". Actually I think docker (and _esp_ LXC) are kinda the least interesting use-cases for container tech/namespaces on the planet.

As for container data format: actually, fedora's official flatpak repos _are_ based on the same OCI image format supported by docker. Flathub (and most other) images us OSTree, which theoretically should allow better de-duplication especially for apps that contain a lot of non-runtime dependencies.

The runtimes can update "under" the apps, and there is a concept of "runtime extensions" to add additional maintained bits to the runtime that can also update under apps. what doesn't update are all the higher level dependencies that don't really tend to provide API/ABI stability anyway but where on a traditional linux system all packages must share a single version. This leads to a proliferation of patching in distros that sucks for basically everyone.

For "why not a self contained binary": Yeah, stuff like Appimage can work. The thing is you actually really need some stuff to get updated underneath the app. Graphics driver userland libraries come to mind, as do platform libraries like glibc (and it's associated NSS plugins). These libraries all have really stable ABIs and are _designed_ for this. You can do this with just a dynamic binary that has most things static linked, ofc, and that can be fine, but flatpak uses containers because they can and because they want to do other stuff besides just bundling dependencies.