I wrote a bit about this dichotomy in this blog post a couple of years ago: https://snikket.org/blog/products-vs-protocols/
I didn't say it but yes, the support for old version for some time would need to be a thing. But it should be defined (say "3 years for last minor release of every version") so it can be planned for
> While there are obviously limits to how far backwards compatibility should go, it doesn't make sense to deny users basic messaging just because their app doesn't implement calls for example. That would just cause a different set of frustrations.
As you clearly didn't bother to read before you answered, here is what I mentioned in comment you didn't bother to read before answering
> with maybe optional "XMPP voice comms", "XMPP video comms" pack of features (for those cases where full voice/video chat is not relevant).
I don't argue for single version, but to very small subset of featuresets instead of sea of XEPs
So you don't need feature matrix, you see "client supports XMPP 4.0", you know what will work and what will not.
I do like Rust development process - stuff gets added to experimental, lives and gets tried by actual users, gets feedback, gets changed and then lands in stable. So stuff looking good on paper but... not being good ends up quickly weeded out.
It did. It was bigger and bigger mess, which feature in which client was supported by what server. I still remember how spotty basic stuff (nowadays) like "send file to someone" was.
And then corporations happened. There was a brief beautiful period of time where you could just put up your XMPP server and chat both with Google and Facebook users directly, but companies figured out closing down their gardens is more profitable and it was no longer the case
> but for some reason recent open messaging alternatives seem to decide to develop new protocols rather than build on top of XMPP.
Coz it is a fucking mess of XEPs spottily implemented between clients and servers, and not always that user friendly.
If you can control server, protocol and client you can just implement stuff. You don't need to make a spec, hope other people's client implement it, start using it in your server, and hope everyone else agrees on it too. And you can just deprecate stuff that turned out to not work well, or just need to be done differently.
Frankly, XEPs shouldn't exist. There should be just XMPP 1.0, 2.0, 3.0 etc. with maybe optional "XMPP voice comms", "XMPP video comms" pack of features (for those cases where full voice/video chat is not relevant).
You either implement all or are noncompliant, no more "well, you send a message but target client doesn't support this XEP, they get garbage"