As I know WireGuard team have no plans and desire for that.

huh .. OpenVPN is UDP by default but you can force it to TCP (we had to do that at one University site that would only open limited tcp ports for us).

I also discovered Wireguard cannot bind to a specific adapter or IP address if you have multiple address on a server. That might not seem like as a big a deal since it only responds to fully authenticated packets, but it does mean that outgoing packets could be leaving from a different IP address than incoming packets.

It's weird that something that's now making it into mainline can't do this very simple kind of bind that almost every other userlevel service, and OpenVPN, can do.

Maybe the best solution is to use a tool like https://github.com/wangyu-/udp2raw-tunnel.

I know, but the performance takes a massive hit. Have you tried it? Maybe it was something I did wrong.

Native wireguard is kernel-only. Udp2raw creates a detour via userspace, so more CPU time, delay, jitter ..

Was it worse than you would expect? Worse than say openvpn or wireguard-rs/wireguard-go?

It's not that bad. Overhead is less than a full TCP encapsulation. I use it all the time

ISPs or countries?

In some cases, countries. In the country I'm thinking of (name omitted on purpose), you have an effective choice of two ISPs, both government-controlled.

Do they actually block/throttle all UDP?

What about encrypted TCP? Do they block/throttle everything but web and recognized traffic? If that's the case wrapping WG or ZeroTier or whatever in TCP would do nothing since it would still look like a weird unrecognized protocol with a max entropy (encrypted) data stream.

Have you taken a look at inlets / inlets PRO? Might be a suitable replacement for your use-case where UDP is not available. https://docs.inlets.dev/