I do think this would be good for power users who want strict isolation between different instances of apps (and I'd also love to see better QubesOS type approaches, using a hypervisor), but perhaps most of this kind of work should be prioritized inside the application itself, using nested sandboxing. That way, the barriers are exactly where the user expects them to be based on the normal behavior of the application. Assuming vulnerabilities in the code that glues it all together don't get explosive, of course.

Web browsers do already use a variety of sandboxing techniques to achieve separation between tabs. Some of these techniques work inside Flatpak, but some of them are broken by Flatpak:

> Ideally, Flatpak would simply support nested namespacing and nested sandboxes, but currently it does not. Flatpak uses seccomp to prevent applications in a sandbox from having direct access to user namespaces.

Some of them are replaced by Flatpak, for application developers that wish to use the APIs:

> What Flatpak does instead, currently, is to have a kind of side sandbox that applications can call to and spawn another Flatpak instance that can be restricted even further

Fortunately, it seems Wick is optimistic about UID namespacing, the main thing stopping Firefox and Chrome from fixing this:

> Wick feels that user namespaces are, nowadays, a well-tested and a much-used interface. He does not think that there is much of a good argument against user namespaces anymore.

Back to the topic of instanced Flatpaks, as I understand one snag is that there is a long-term desire (by app stores/platforms in general) for a full boot-to-userspace code-signing setup to be tied into the sandboxing. The identity of each application should remain the same (unless specifically overridden by a power user) so that a fake version of an application can't adopt an existing application's confidential encrypted files if it doesn't meet the codesigning requirements. I guess one solution here would be for the segregated instances to be nested inside the application's identity, but that's getting quite complex. And we don't even have encryption nor any functioning secure boot + confidential computing implementation yet -- all we really have so far on this front is the reverse domain name notation being verified by Flathub, with filesystem access sandboxing to keep these folders separate.