I wish the Matrix/Element folks the very best of luck, because they're pretty aligned with Zulip values-wise.
That said, I don't think you should expect a Zulip-style threading user experience in Element anytime soon. Regardless of how the Matrix protocol for federation between servers is extended, providing the "Zulip user experience" would likely require a major overhaul of both their client/server protocol for Element and their client user experience. (Also, the proposal you link is for HN-style threading, not Zulip-style topics).
I don't understand Element's internals, but my basis for this claim is a huge portion of all technical and design work we do on Zulip wouldn't be necessary or would be much simpler if Zulip didn't have topics (E.g. the architectural decision criticized in https://news.ycombinator.com/item?id=27150492 is a good example). See https://news.ycombinator.com/item?id=27150196 for a few more examples. I imagine Element will only invest in all of that work that if they believe it's important to their business.
As an outside observer, Element's business focus seems to be on competing with WhatsApp/Messenger/Signal/Telegram/SMS, not Slack, so while I'd love to see Matrix/Element borrow Zulip's topics model, you probably shouldn't hold your breath.
Thanks for pointing out that the upcoming Matrix threading model I linked to isn't the same as what Zulip has. I wasn't thinking about Zulip's model correctly.
After doing some research, I think you're right that the proposal won't immediately enable Zulip-style threading. Though, it seems like a small change on top of the linked MSC (Matrix Spec Change) proposal would enable Zulip-style threading.
If Matrix had an event type that created a "topic", that's all you would need. The linked MSC is very general and allows events to reference arbitrary parent and child events, and allows updating those parent and child relationships. If the parent is some kind of "m.topic" declaration event, maybe that would be enough.
It's also entirely possible that Zulip style threading doesn't even require that new event and I'm just not familiar enough with Matrix to see how.
---
Your points about how advanced the Zulip client is, though, are very true. It will take a ton of work for Element or some other Matrix client to catch up. You guys really built something impressive there.
I look forward to seeing what Zulip comes out with in terms of federation. It's a tough problem.
That said, I don't think you should expect a Zulip-style threading user experience in Element anytime soon. Regardless of how the Matrix protocol for federation between servers is extended, providing the "Zulip user experience" would likely require a major overhaul of both their client/server protocol for Element and their client user experience. (Also, the proposal you link is for HN-style threading, not Zulip-style topics).
I don't understand Element's internals, but my basis for this claim is a huge portion of all technical and design work we do on Zulip wouldn't be necessary or would be much simpler if Zulip didn't have topics (E.g. the architectural decision criticized in https://news.ycombinator.com/item?id=27150492 is a good example). See https://news.ycombinator.com/item?id=27150196 for a few more examples. I imagine Element will only invest in all of that work that if they believe it's important to their business.
As an outside observer, Element's business focus seems to be on competing with WhatsApp/Messenger/Signal/Telegram/SMS, not Slack, so while I'd love to see Matrix/Element borrow Zulip's topics model, you probably shouldn't hold your breath.