>> you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure
> But I don't want to trust my community to someone providing me infrastructure.
I mean, that's always the case in the end, isn't it? Your identity is tied to your server, and that's pretty much what defines the whole thing as being a federation and not P2P (that applies equally for XMPP as for Matrix).
As long as migrating from provider to provider is easy and convenient (which amounts to acknowledging that all providers eventually come and go, what centralized service users are in denial about), I don't see it as being a fundamental issue.
It's also easier to mitigate this aspect in XMPP-world where being your own provider is orders of magnitude easier and cheaper compared to running a matrix homeserver and federating at scale.
Also, talking about infrastructure, the situation is quite worrisome in the case of Matrix, I'd say: only one entity is competent enough (or has enough cash committed) to running large-scale: new vector. And it runs that of matrix.org, kde.org, fedora.org, mozilla.org, …. It also happens to be the one specifying and implementing the (incompletely documented) protocol, conveniently.
>> In practice the room survives in a "split brain" mode where different users see different participants
> Even if this is true (I haven't see it when servers go offline) this sounds like a bug that can be improved over time. Not a reason to give up.
It's a very very hard problem to crack. They've been at it for 10 years across many iterations of the protocol: https://telegra.ph/why-not-matrix-08-07 . I like to think that it can be solved the same way I want to have closure about P=NP, but I also challenge that this is a meaningful and practical approach in this context.
> This is true, as I said users are federated and suffer if their homeserver goes down. But it is a huge difference to be able to set up a second account on a second server and continue participating rather than needing to convince a large group of people to switch to a different room.
Yup, and that's all pretty and neat in theory. In practice it happens every so often that rooms just break for inexplicable reasons, and that people must migrate anyway. Not all members do, because for some, everything still looks like business as usual (happened again few months ago with the 3D Printing space), and trust me, this is much more eventful and disruptive than freenode committing seppuku once every quarter century, or with large XMPP networks going under.