Flatpak in theory vs flatpak in practice are different things, as you highlight yourself ("...does not use standard file choosers, file APIs, etc.").

Suddenly, it's now on app developer to support the packaging system and not the other way around.

I mean what do you want to have happen? ptrace every application, stop on every openAt(2) call and pop up a permissions dialog?

macOS can get away with solutions like this because they control the kernel and userspace but on Linux it’s a much tougher problem.

And also because macOS has only one desktop environment :)

But that’s exactly what GTK and QT have! It’s what to do with apps that don’t use some abstraction that supports portals that’s the issue.

Well, there’ll always be a long tail. But if you start with the popular apps and frameworks first, you get the most bang for your buck.

It wouldn't surprise me however if sandboxing is only a good model for GUI not console app.

IIRC the Windows 10X approach will be to put all non-sandboxed apps in the exact same environment.

As mentioned above, Flatpak is already doing the two most popular toolkits. Programs just don't use toolkits to open files. So there is not a lot of "buck" here, and the tail is rather long.

Can't the sandbox override the corresponding syscalls? E.g. open() and readdir() which then block until the user has selected the file? This means you'll have to click the file twice (once for the sandbox and once for the application) but at least it is more secure.