A lot of Flatpak's design is a great prototype, but it's somewhat worrying (for the ecosystem in general) that this was taken as a final design and being pushed out in all directions.

Portals are just a terrible design for a security boundary: all interfaces clobbered up into one huge daemon, which also deals with a lot of the internals of Flatpak/Snap. If you want your sandbox to use portals, you can't, because it relies on internals of both of these sandboxing mechanisms. The devs have confirmed they won't implement an API for other sandboxing engines to integrate with them.

The whole system also deeply intermixes the package manager and sandboxing engine — to the point where you can't use the sandboxing engine with your favourite package manager, and you can't use the package manager without the sandboxing engine.

It seems that the mentality is: all other distributions are irrelevant, all other sandboxing engines are unsupported.

And then desktop applications start having first-class integration with Flatpak, and start having issues everywhere else.

You already need to set up Flatpak's daemons for using some features in Firefox (like screen sharing, where the native interfaces aren't supported), and it seems that the plan is to do the same for other features.

In the beginning, Flatpak was seen as savior for the Linux desktop ecosystem by making more applications available for more distributions, possibly packaged by the upstream maintainer, but they didn't realize that Flatpak resp. Flathub are actually just another distro with its own builds, repository, package manager, package format and community.

On the security side it was also seen as the only way forward, but it's just opt-in sandboxing. That's still possible to achieve without flatpak by using the underlying sandboxing tool (bubblewrap), but not as user friendly as using the flatpak provided defaults.