> Or have a Wireguard 2.0, where all participants need to upgrade in lockstep, with no backwards compatibility (actually sounds attractive: some churn from time

> Or have a Wireguard 2.0, where all participants need to upgrade in lockstep, with no backwards compatibility (actually sounds attractive: some churn from time to time, but none of the avoidable headaches)? I think it's basically the plan. Even with protocol negotiation, replacing an existing crypto algorithm would be a breaking change anyway. Furthermore, it should be possible to preserve backward compatibility using a reserved field without a heavy-weight, full-fledged protocol negotiation. Entering a different code path if the message is tagged "version 2" should be enough.