You want the meaning of sandboxed in flatpak changed, and for it not include access to the home dir? That seems fair. But with the current UI, I think most people expect that a video player can open video files in their home directory.
Though the trusted filepicker is tricky to do when one logical document consists of multiple files. For example separate subtitle files next to a video file are common.
Certainly one could select all the files and drop them in. But that's asking a lot of the opening program, and isn't usually how they're set up.
For multiple files per document, the solution would be either multi-file select (bad) or allowing apps to specify very simple rules for additional files, ie "removing extension, also mount all files starting with that name".
The filepicker could integrate that and either show all those files as a single document or select all files for a document visible, so the user is informed.
..à la Qubes.. https://www.qubes-os.org/doc/copying-files/
I think the Downloads, Documents and Movies folders people tend to have etc. those major sub-folders would be enough for normal use.
Also, perhaps file type limits could be imposed that mean at that files are only accessible to apps that can open them. Of course, I'd want my text editor to be able to open files across root file system, if I open it as root - so I can see how quickly a person can want sandboxing, and then also want none - but the less apps with privileged access, the better.
Also I think some people had hopes it would be closer to IOS level sandboxing, which is heavily restricted on file access, and frankly can be annoying because of it, but does have the security benefit at least.
Also, the security update gripe is significant. The isolation of packages only matters if it works. Like at least if I run stuff myself inside container, I can choose to update the underlying OS and force certain packages etc. at the same time as sandboxing, and mount only certain folders if I actually need them.
I think it's hard to make it both simple for users and powerful enough provide the levels of granular access I'd expect for context specific sandboxing. I would want a principle of least required privilege, with some ability to escalate it (like Android asks me all the time if I want to allow software to do stuff at point of the privilege being required).
I had high hopes for Flatpack, Elementary OS went all in on it for a better way to deliver their curated apps. https://blog.elementary.io/elementary-appcenter-flatpak/
I guess though, they curate and approve the apps, so perhaps they are able to make certain assurances that are not universal to Flatpak availability.
The texteditor gets no FS access. Instead the call the portal to request the user to pick a folder (for projects) or file with a specific ending (the compatible file formats or if folders can be picked can be defined statically for most apps).
If the app was started with root privileges, it gets no root privs but the portal transparently translates it's IO calls to the actual file.
But only that file. So even if the text editor had a CVE, it couldn't overwrite arbitrary files, still needs permission from the user by showing them a file picker dialog.
And you could still ban certain directories, so even if you started as root, the text editor cannot access /etc/sudoers and /etc/passwd, for example.
That's SELinux, if configured well. Files are labeled according to their function and access to these files is whitelisted according to the security label of a process. For example, no security labelled process can access my private ssh keys, that's guaranteed.
It's just a shame that SELinux has such a documentation and UX issue, so almost no one uses it and almost no one uses it well - except for package maintainers and some application developers.
It's fine if it's a trade off between usability and security but then they shouldn't call it sandboxing or make it very clear that that's the trade off.