I'm responding to a comment that expects app developers to make do with a specific version of a library. That expectation seems to be in line with that in the post that TFA responds to, which is unsurprisingly addressed in TFA.
There's a lot of "it's not that hard"s in that post. Of course we all prefer software that just works after being installed with the distro package manager. I don't want to install a container runtime to run grep or netcat or whatever. Meanwhile app developers have to balance their own priorities, it gets complicated, and, I guess increasingly often, "ship X feature to Flatpak users" wins over "make the lives of users/maintainers of Fedora easier". It's just another tradeoff, and sometimes the cost of making do with one version of a library isn't worth it.
At one point we have had to maintain support for 3 different versions of libpng in an application we were working on - just to make it work on 3 different popular distros. (Ubuntu via PPA, Arch via AUR, OpenSuse iirc).
For the popular applications, it maybe that distro maintainers send you the pull request. But for small time applications, all you get are bug reports that the application is crashing on X distro, fix it.
We ended up moving to AppImages to not deal with all these headaches anymore.
Distros themselves run on very few volunteers. So it's usually a painful process to even get your application packaged into distros like Debian etc .. when dealing with public domain libraries that aren't available in their repositories but you aren't allowed to statically link to them.
But why couldn't you just use 1.2, is the question?
I've been bit by this style thing plenty of times. Just recently, I started a python project and used 3.11, only to realize I was targeting AWS Lambda and at the time 3.9 was the best they offered. I could have tried maintaining two versions and worked around that, or I could change completely to 3.9. (Now 3.10)
Did I lose on some things? Yeah, the switch stuff, in particular. That said, it was far preferable to a complicated build chain that tried to support both.
It was a decade ago, so my memory is a little fuzzy on this.. but that's one of the commits I shared above. Trying to force it to use 1.2. But there was a Gentoo user who ran into issues with that and i had to revert it.
But you do see the problem right? How distros end up creating this weird situation of certain libraries not being available in certain places. They won't even let you statically link your program to those libraries to it into their repositories. It was easier to just give up.
This isn't really a "distros" problem as it is a "dependencies are hard" one. Having many targets for deployment makes it visible, but just look at the complexity of targeting all browsers to see how it is dealt with for ostensibly simpler requirements.
I imagine at some point people were like "is it more work to investigate this (and similar future questions) or switch to shipping AppImages instead". :(
There's a lot of "it's not that hard"s in that post. Of course we all prefer software that just works after being installed with the distro package manager. I don't want to install a container runtime to run grep or netcat or whatever. Meanwhile app developers have to balance their own priorities, it gets complicated, and, I guess increasingly often, "ship X feature to Flatpak users" wins over "make the lives of users/maintainers of Fedora easier". It's just another tradeoff, and sometimes the cost of making do with one version of a library isn't worth it.