What are the implications of these changes for someone else wanting to make an interoperable Matrix server or client from scratch?
Will it be easier than before?
(I've written several IRC clients, and a simple one could be done in an afternoon with only a sockets/TLS library. But when I looked at Matrix briefly, implementation seemed very big-moat. And now it's a rapidly moving target.)
Matrix clients should be super easy to write - e.g. https://news.ycombinator.com/item?id=20948530
Servers are definitely harder - it's probably similar complexity to writing a git implementation (given it's basically doing the same operation: synchronising DAGs of commits between replicas of a chat room).
In terms of it being a rapidly moving target: from memory we've never broken backwards compatibility on Matrix since day 1 back in 2014. "Matrix 2.0" is not a breaking change; it's just adding some new APIs to change performance to be O(1) rather than O(N) (and switching to OIDC for auth and native VoIP for multiparty).
So, overall, I'd say it makes things easier: both Matrix client & server authors will no longer have to mess around implementing custom auth (which was a huge burden to get right), but be able to use existing mature OIDC implementations. Meanwhile, the new sync API should be as easy as the old one (although we haven't really done a like for like comparison yet, given we've been obsessing about driving the new sync API as efficiently as possible)
I don't see the end-to-end encryption there. Nor any of the other tablestakes features.
Not sure which "any of the other tablestakes features" you have in mind... obviously if you want loads of features, then you're going to have to write a whole bunch of code to implement them in your client, or build on an existing SDK like matrix-bot-sdk, matrix-rust-sdk, matrix-js-sdk etc. Not sure that's a disadvantage of Matrix though(!)