Can we talk about the rude installers not asking for installation locations?

I agree with the sentiment; I also want to control where things are installed. But the framing of the technical problem here is totally backwards.

The operating system or application manager within the operating system (what does flatpak consider itself?) should decide where all application state goes. The application shouldn't ever prompt the user for this, it should just assume a path inside a sandbox. That path inside the sandbox will get mapped to where-ever outside the sandbox, and that's where the user exercises control.

We already see this pattern emerging with docker images. Everything assumes `/data` is a good place to store things, and `/config` is a good place to read configuration from. I want every application to do this. If I want it to store state, then I'll decide to map those to directories that are persisted.

100% agree with this.

But what about for state that the application doesn't really "own"? e.g. I want to open a PDF in an editor. The PDF is in my documents folder, and I don't want to expose all of my documents to the application in its sandbox.

Fine grained access to single files should be given out using a file picker. The application manager passes in a socket to the application sandbox. The application connects to that socket using a known hard-coded path. It sends a message (client->server) over the socket, the listening file picking process opens a new GUI window to prompt the user to select a file. The user picks a file and a file descriptor is sent over the socket to the application (server -> client).

Spoken like a Linux software developer, I suppose. As a Windows user of generic software (image editing, video players, games, etc.), I want to be able to control such crap. I have a media player that can easily fill a small HD with its mindlessly huge DB, for instance. Rather than manually cleaning periodically, or upgrading my $y$tem, it's easiest to say "Software, store your data here".

> Spoken like a Linux software developer

These techniques are pretty general purpose. They aren't merely a cultural artifact of Linux or FOSS. Anyone trying to sanely deal with authorization is going to stumble upon sandboxing, and capabilities, and the principal of least authority, etc. if they look hard enough.