Multiprotocol clients and transports are a dead end.
Most walled garden messaging service developers are openly hostile to third-party clients - this goes back to early 00s and ICQ war against QIP and other much better clients. Modern technology and app distribution model has made it far easier for service owners to enforce their rules of using their service.
The problem is not the client at all. Look at the history of libpurple/gaim. My chat setup used to be an irc client connected to bitlbee (which uses libpurple), and (way back when) the various chat system owners would either intentionally or unintentionally break the integrations fairly regularly.
They have no incentive to keep their API stable since they control their official client.
On top of this, when you try to bridge disparate comms platforms together, you end up with the client having only the common subset of functionality, or with the client emulating functionality clumsily.
The example I'm thinking of is in iMessage, if you're on a group text thread with people who are on SMS instead of iMessage, "tapback" reactions (the thumbs-up, exclamation, haha, etc ones) show up as "<name> emphasized '<the full text of the message they !!ed>'".
For me partial support is a key feature. Not having to send read notifications, not having to look at bs like stickers and the ability to ignore chat deletions is really great about bridging :)
it's way harder to make all Matrix clients support all protocols and somehow sync them properly than to write a App Service that can be plugged to a server.
What you refer to is called 'transport',such transports for xmpp exist for more than 20 years.
They didn't fly because service owners don't really want them to. Sometimes services resist actively, sometimes passively. The protocol you use is irrelevant, xmpp, matrix, email, whatever - this is never-ending game of catch up which the service owner will win, because he needs users to use their stock app and all their metadata.
They're called bridges because they connect the Matrix server to the other servers. They aren't independent. And reverse engineering protocol changes wouldn't be easier if they were.
What is discussed here is nothing new. I ran a jabber ICQ transport for myself and colleagues as far back as in 2005. It was a constant source of pain. Whenever the ICQ protocol changed, you had to wait till developers of transport updated the lib, so you could resume the service. If anything, now it is far easier for service maintainers to update the protocol because the app distribution model got much more efficient - just one tap on the smartphone, so you can just suspend the functionality until the users updates, whereas ICQ devs had to rely on users manually downloading and installing the update to their official apps, slowing the update cycle by many months/years.
Any one of those services can instantly plug up the hole (especially the Apple one) and it's over. Building a business reliant on other company's platforms rarely ends well.
Most walled garden messaging service developers are openly hostile to third-party clients - this goes back to early 00s and ICQ war against QIP and other much better clients. Modern technology and app distribution model has made it far easier for service owners to enforce their rules of using their service.