Matrix is very extensible too; it's just that we aim to merge extensions as rapidly as possible into the core monolithic spec, rather than having them get fragmented into optional extensions.
I wonder what happens when there's 10 implementations of the matrix spec controlled by different groups. Being able to indicate where the implementation gap is seems like a strength rather than a weakness.
Hm, even when there are 10 different server implementations (or the ~50 client implementations there are today), we’d hope they would align to the same spec - just as with HTTP, SMTP, TCP/IP etc. There’s room for experimentation without introducing fragmentation, and any useful experiments would hopefully rapidly get merged into the spec. And if they don’t then yes, you risk a fork on that particular feature (the equivalent of only Exchange supporting email recalls, or browser vendor extensions), but it’s not the end of the world.
it really depends, if the features are difficult to implement it may not be very quick at all, we see this with XMPP often where features take years to implement or never appear. If a homeserver targets a particular use-case then they may actively choose to ignore certain features that are not relevent. Really when people talk about the flaws of XMPP they often have in mind the problems of private e2e encrypted chat on mobile which is a hard problem to crack, but there's many more private servers inside organisations that don't even federate and work fine for how they are used. This flexibility perhaps makes it better to view XMPP as a toolkit for building networks out of, similar to how IRC networks which have a converged set of servers but outside that network all bets are off. The idea of viewing XMPP as a single network inevitably causes it to look fragmented but there are pockets within the network that interoperate just fine they just don't identify themselves as a group.
