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.

I like to post issues like that in the bug tracker with concise phrasing like “Why can’t the file editor edit files?” Give them nothing to think that you actually know the answer, make them spell it out.