If we were going to completely rely on flatpak to solve our problems, we would be able to break ABI every 6 months w/ each GTK release. But that is not a tennable solution today (or likely ever). Distributions ship desktops which will have applications that naturally live outside the flatpak runtimes.
Just so I understand, would the ideal goal in that scenario be fat app packages or maybe even statically linked apps? If the API/ABI support scheme as blogged about is adopted, maybe that's the practical solution.
Am I wrong, or does this sound like GNOME's trying to be a more central runtime and subsume parts of a linux distro in full. If that's true, it certainly doesn't sit well with me, if I consider how and why I've been using Linux for 19 years. I've never been able to use a desktop environment because they're always limited and do not allow me to express my way of working like my old FVWM config or current XMonad config do. It's like the difference between SublimeText and Emacs users. Different needs mean different types of users and Gtk and Qt must stay GUI toolkits, two among many.
> Am I wrong, or does this sound like GNOME's trying to be a more central runtime and subsume parts of a linux distro in full.
I don't think so, but GNOME does have a long history of diving down the stack and fixing problems when we run into them in lower levels. Of course, fixing long standing bugs that are often depended on corner-cases is certainly going to require additional engineering (the current tmux/screen situation comes to mind).
These things are largely a thankless task, and often a hostile process. Everyone seems to want their bug fixed, and nobody elses.
We very much need everyone interested in our shared commons to come to the table and discusses their needs. Otherwise it's not a commons.