The protocol is quite easy to get into, it is well documented to the extent that it is easy to believe that it is in WireGuard's interest that more people develop software that supports the protocol.
Maybe the WireGuard homepage should make an official statement that anyone who implement the protocol and release a client is no longer welcome in the community to discuss the protocol or listen when other people discuss the protocol.
The WG author mentioned in the mailing list that he has reverse engineered Tunsafe and found security flaws. I would like to see that he presents these security shortcomings in order to legitimize his claim instead of keeping it secret. As he is a representative of a security company, it might be a good tactic to not hurt his reputation as it is practice in the security industry to share such information.
I'm insanely impressed that he's come up with something so good, and I have no knowledge of cryptography and writing truly secure code, so I don't like to complain like this... but it would be nice to have a real timeline so that we can make our own decision about whether we want to use the closed source alternatives.
I don't know either person at all, I only found out about tunsafe and the "controversy" a few hours ago after seeing this post and googling for the windows alternatives that "are not recommended" but are mentioned on the wireguard site.
I admit I did editorialize a bit more than I should have.
However that will not really be an issue for a many years and there are many ways how that can be handled in the future.
Where do you have the information about how Wireguard would handle such a transition from? Looking at https://www.wireguard.com/protocol/ I can see no protocol version or other means to distinguish between an old and new version of the protocol. Also this would introduce additional configuration and a negotiation step which seems to run counter to the motivation of the project.
Not preparing for for this inevitability seems foolish which leads me to believe that this was not an oversight but a deliberate design decision by the creators of Wireguard.
 Page 10 onwards of https://www.wireguard.com/papers/wireguard.pdf
Also looking at the struct it seem the three bytes are only reserved in order to align the following fields on 4-byte boundaries.
If the authors had the intent to allow for some kind of asynchronous update path then surely this would be built explicitly into the protocol right from the start.
Fortunately I know exactly what I was thinking. Each message has an explicit type. The set of types exists in the first byte with the remaining three reserved for future additional use, perhaps for naming types. The cryptography is tied to the version by way the identifier and construction constants.
Regardless, it is clear that there are numerous ways that can be backward compatible to extend wireguard into v2. IIUC, the deliberate design decision is that "we are not baking any specific one-true-way". It's not "not preparing for the inevitability", it's "the way protocol agility has been done so far has failed, we defer this decision closer to the time we need it".
I rather put my stack into the best currently known crypto rather then a highly complex cipher negotiation process.
Having said that I still would have preferred for something like a single increasing integer as the "cipher suite version". This would have allowed for the option of updating Wireguard asynchronously on both ends without any additional configuration or cipher suite coordination with the peer.
This already essentially exists. If the first byte of an initiation message is 0x1, then it means you're using "Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s" "WireGuard v1 zx2c4 Jason@zx2c4.com". It seems like this thread is going in circles based on incorrect information about how the thing actually works.
Have you considered mentioning the way you intend to deal with cipher breakage/deprecation more explicitly on the Wireguard page?
Why does the "increasing integer" matter to you? In what way is it better than "I am willing to protocol 1, 4 and 7" (implicitly "but not 2, 3, 5, 6, 8, 9, 10,"...)? And the "I am willing to .." is just a successful handshake. You try in order of preference; If you succeed, other side supports it. If you don't, you go to the next one. Wireguard does not produce a response unless to a non-confirming attempt.
The last one highlighting the last blocker for any serious adoption.
Cryptographic knowledge is much more available today than it was 17 years ago when OpenVPN started, so that has probably helped. Some of the constructs used in Wireguard (such as ChaCha20Poly1305) are also quite recent, and didn't exist when OpenVPN started.