the ability to separate switch between programs and their windows

What do you mean?

I agree. Flatpaks have similar challenges. I understand the dilemma, I understand what they’re trying to do and what they’re trying to solve, but shifting responsibility for these sorts of things from “here” to “there” is not actually solving the problem it’s just moving it, and often moving it to somewhere that someone who has no business dealing with it will ultimately end up dealing with it in a way that’s even worse than what you started with.

Personally I try to be pragmatic and not ideological about software packaging. I usually prefer distro-provided deb packages whenever I can get it as a strict first-place-to-check, and I try to convince myself to use that even if it’s a somewhat older version or kind of stupidly packaged, falling back to the project’s own deb repos if they have them for more up to date versions, and if that fails I might consign myself to building from source or banging my head against a docker, unless I really absolutely need to use some other packaging option some specific reason. I’ve even used a flatpak occasionally (often for something I would like somewhat sandboxed) But snap is pretty garbage and has few redeeming features and I’ve never really felt the slightest interest in using it for any reason.

It’s a mess, but it’s a manageable mess, mostly because I’m forced to manage it whether I like it or not. This is the unfortunate reality of software packaging on Linux. With great choice comes too many choices. It’s a tradeoff I’m willing to make, because I like having choice.

Except for when sandboxing is better, like for server-type things that need to “just work” and won’t directly interface with anything else on the system.

Like, a WiFi mesh network controller has no need to access anything I’ve the system at all and users will only interact with it by a web portal. Docker (or an alternative) is perfect for that.