These things aren't WireGuard's job any more than they were IPSEC's job. What's supposed to happen for people who care a lot about these things is for systems to get built on top of WireGuard to provide them. That's happened for the commercial market, where things like roaming and NAT traversal are key features, and so we have Tailscale. It sounds like you're identifying an open source privacy project built on WireGuard that want to exist. Why not try to put one together?
This is when what makes WireGuard very performing also makes it very difficult to extend. Being in the kernel means extending it in userspace hurts its performance.
Well then how can you claim “most of you might need can be built atop a very performant base layer” without understanding what the grandparent comment (https://news.ycombinator.com/item?id=28579704) says about WireGuard lacking obfuscation?
WireGuard encrypted UDP packets have obvious signature due to the packet type field in the header being in cleartext. DPI can easily filter/drop WG traffic just by checking the first few bytes of each UDP packet and doing simple statistics.
To obfuscate in this context means to morph WireGuard encrypted UDP packets to look like something else (e.g. VoIP traffic).
Current kernel-based official WireGuard implementations leave no possibility of doing so while staying in-kernel.
I was answering to the first part of his comment, about bringing the whole kitchen sink in a tunneling protocol instead of having composable tools allowing for things the designers never imagined.
But OK, this doesn't cover the second need, I'm guessing what you need is down one layer, and should be done in kernel if you really think it important, but how does wg prevent you from doing that?
Build your tunnel obfuscator one layer down (I did some stateful, user-land driven, packet patching not long ago, with ebpf, it is not easy but the tooling is getting better. It seems the new way to do things nowadays anyway... And it runs in-kernel. Then lay wg above it. But having the wg codebase do what in fact the kernel should propose (pluggable transports, etc.) seems... asking the wrong team.
The Linux kernel network stack is already plenty composable without ebpf...
These things, like user accounts, more auth methods, flexible endpoints, IP pools, ..., should be integrated in a product in a secure manner. What wireguard does is the irresponsible lazy approach of leaving everything up to the VPN providers and webinterface-monkeys. Who will surely mess up a lot of the upper layers that provide all the necessary "comfort" features. After which the wireguard crowd will wash their hands with the Jobsian "you are holding it wrong".
