I'm curious how that's supposed to work with stable distros like debian, ship protocol upgrades as security fixes or at least each point release (+LTS?)
If it's in rust or anything that requires new compilers to build that doesn't sound easy, debian stable ought to be able to communicate with current software but the stable that uses rust 1.63 (2022-08, 1 year old as of first bookworm stable release) and supported (without any LTS) until 2026-06, at which point rust will be 4 years old and it'll be almost impossible to build anything with it, which is required for official packages that can't depend on rustup or similar... LTS being even more out of question.
This is quite interesting. How to maintain backwards compatibility while retaining the flexibility to move forwards is always a huge tension in protocol design. Look at SMTP!
Essentially, mandating a window of version compatibility from the start at least communicates the intention. Whether it works in practice would depend on how well everyone actually tries to stay to stay up to speed, and whether network effects can be used to keep everyone on board.
The traditional way to solve this was to keep the protocol at a 0.x version until mature enough. "Enough", not absolutely perfect.
(Of course this can be abused, like with gmail being "beta" over five years.)
After you hit 1.0 then accept that any breaking changes are Big Deal which require a new protocol major version and should only happen once in many years (unless there is a fatal security flaw discovered).
Perfect is the enemy of good. People whine about details with email, but this is why email continues (after 40+ years) to be the most interoperable communications mechanism in the world across everything.
I assume for this to be successful, some large/important set of clients will have to be on board with proactively updating, and drag the rest of the ecosystem along if they still want to be connected?
0. https://github.com/alacritty/alacritty