The enemy of my enemy, eh?

Fair. Also, flatpak does not try to break everything by default, which is a plus.

Laughs in nixpkgs

You could make aliases for each program, but I agree, there should be a way to set it up so they resolve automatically.

You can symlink /var/lib/flatpak/exports/bin/org.gnome.Lollypop (if you are using a system installation) or ~/.local/share/flatpak/exports/bin/org.gnome.Lollypop (if you are using a uset installation) to ~/.local/bin/lollypop and run it as lollypop.

Well, Flatpak installs aliases, so as long as your distribution - or yourself - add the <installation>/exports/bin path to $PATH, then you'll be able to use the application IDs to launch them.

And if you want to have the Flatpak available under a different name than its ID, you can always symlink the exported bin to whatever name you'd personally prefer.
I've got Blender set up that way myself, with the org.blender.Blender bin symlinked to /usr/local/bin/blender, so that some older applications that expect to be able to simply interop with it are able to.

glibc 2.36 is all you'll ever need, okay? Go away with those goddamn backports!

I know, right!? Add gimp to that list as well. I can go on and on about shortcomings of gimp despite being a happy user. The average gimp hater, on the other hand, doesn't have anything to say besides "the UI is dumb and I can't figure out how to draw a circle"

Wayland gets the hate because compositors are authoritative so you cannot e.g. install your own window manager, taskbar, etc. It would be good if there were specifications governing these, but there isn't.

Typically Windows applications bundle all their dependencies, so Chocolatey, WinGet and Scoop are all more like installing a Flatpak or AppImage than a package from a distro's system package manager. They're all listed in one place, yes, but so's everything on FlatHub.

I'm not sure where you're getting the idea that Flatpak aren't centrally managed...

I think containerization for security is a damn good reason for virtually all software.

Someone got to say it....

There is no Debian if everything was a pile of Snaps/Flatpack/Docker/etc. Debian is the packaging and process that packaging is put through. Plus their FOSS guidelines.

So sure, if it's something new and dev'y, it should isolate the dependencies mess. But when it's mature, sort out the dependencies and get it into Debian, and thus all downstream of it.

I don't want to go back to app-folders. They end up with a missmash of duplicate old or whacky lib. It's bloaty, insecure and messy. Gift wrapping the mess in containers and VM, mitigates some of security issues, but brings more bloat and other issues.

I love FOSS package management. All the dependencies, in a database, with source and build dependencies. All building so there is one copy of a lib. All updating together. It's like an OS ecosystem utopia. It doesn't get the appreciation it should.

I do sort of wish Nix was a more popular distro agnostic solution

Also at least let me compile it myself if not in a repo 😩

Back in the day, when I installed my very first Linux OS, I had a wireless stick from Netgear. Wireless Drivers back then were abysmal, so I had to compile them from source (literally 15 mins after seeing a TTY for the first time). After I had found out how build-dependencies and such worked somehow and ./configure completed successfully for the first time, the script ended with the epic line:

configure done. Now type 'make' and pray

Because it's always so easy to compile everything you need from source! Just make sure to download, compile and install the dependencies first as well. Oh, and the dependencies' dependencies. And the ones from them. And so on. Unless you're lucky enough that there are already packaged dependencies available for you. Don't know how to compile? No problem, just read the documentation. You can be absolutely 1000000% dead serious sure that everything you need to know is documented and extremely super duper easy to understand if you don't know the source code or barely know how to code at all. And if not, maybe you can find the bits of information on the respective Discord server. It will probably be also very intuitive to know which build options you have to set in which way and which ones even exist. And that without causing conflicts with other packages you need to compile. Still got got problems with compiling? EZ, just open a bunch of issues on the respective GitHub pages. (If present. Otherwise, try to find another way to contact devs and get support, Discord for example.) Maybe, about six months later you're lucky to get a response. And if not, don't worry. Some will tell you, you should RTFM or are an idiot. Some will just close the issue because your platform isn't supported anyway. Then you know, what you did wrong. Also don't mind if your issue gets ignored.
If you finally managed to compile everything from source, congratulations! Now run the program and test if everything is working. If it's not or if it is crashing, don't worry! In developed and civilised countries you can just buy a shotgun and blast your own head away to end this suffering.

EZ! Just compile from source! /s

Valid solution, but I miss unified updates with appimages and such