>This is the same as with files. And in either case in practice there isn't really that much of an issue.

No there is an issue, there's a good reason a lot of apps now are using things like sqlite to store data. Yes it's still just files but it's got transactions and journaling and atomic updates and backups built into the API so the chance of accidental corruptions is very low. The Xrm functions never got that, maybe someone could add them (and break everything else in the process) but obviously that never happened.

>These designs do not come from some god, they are decisions people (the developers) make.

Who have to make them under constraints given by the target users. As a developer you don't get to decide on these constraints, and often the constraints can be conflicting depending on which users you talk to.

>Nobody aside from you brought up anything about doing things for free or not, it is completely irrelevant to the discussion.

No, wrong. It's completely relevant. This is open source, all work is going to happen for free by default unless you find somebody to pay for it. That's the way it always has been and nobody has wanted to pay for it thus far. You're not making a direct appeal to businesses here or putting up any of your own money up front, so you're effectively suggesting that random community members do it for free. If you know somebody, an "unturned stone" who does want to pay for it then I suggest you take their money for yourself since you seem to be a lot more invested in this than anyone else in this comment thread.

>In other words if something is technically possible then it is not a technical issue.

>My claim is that it is a social issue because people decide to not do it not because it is technically impossible but because they do not think it is worth to do it.

And you're still wrong here because this is not technically possible. Being unable to accomplish something technical within the budget constraints means that it's not technically possible. It doesn't matter if they think it's worth it or not, the physical resources are still not there to actually complete the task. It's not that I dislike you saying this, I dislike how this blatant and intellectually-dismissive nonsense persists as a meme. It's incredibly rude and disrespectful to people who work on this. It's like you're framing it so that if only a couple people changed their mind then everything would be just peachy, when I suspect you know very well that it doesn't work that way. You're ignoring the very real technical reasons why the divergence happened to begin with and you're trivializing the work that needs to be done here. But then you go and say later that it would actually not be easy to do this. See where this cognitive dissonance is? Again if you think everyone else is confused and you're the only one who recognizes how much this is worth, then I encourage you to dedicate your time and money towards it. I'm really do hope I'm wrong and you end up successful, but you'd be trying where many others with a lot more resources have failed over the last 40 years.

>especially when you take into consideration that both Gtk and Qt break their ABIs at every major version

This is a totally different issue and has nothing to do with the availability of said toolkit.

>that is in pretty much every Xorg/etc installation

Yeah so is GTK1 and GTK2 at this point, those were widely ported to every Unix and also haven't seen updates in like 10-20 years. Remember that Win16 still technically works in most windows installations. There are still a huge number of reasons why nobody should build a Win16 app in 2022. Nobody is going to keep insisting that Win16 is currently the default Windows toolkit. I really have no idea why some Unix geeks try to flip it around and use the same logic to claim that Xaw is still somehow relevant. They're both (relatively) ancient APIs from the same time period.