But to be fair, this doesn't work perfectly (especially if you have certain firewall rules that block UDP packets if they're not part of the what the firewall thinks is the same "connection", if both peers change their IP at the same time, or if the peer whose IP changed was rebooted or reconfigured before the other peer received a packet from its new IP addreds) but it really does work surprisingly well. For those (important) corner-cases, I would imagine that higher-level tooling such as NetworkManager would do the DNS checks you're talking about.
The non-roaming end (end with a known endpoint) will update the IP of the roaming end every time a handshake occurs. The issue the OP is getting at though is when both ends are roaming. In this case the, er, "more roaming" peer needs some way to find the other peer. There are a lot of technically interesting ways that we could solve this problem, but in practice it's pretty much always solved by dynamically updating a DNS record. I would say Wireguard handles this scenario about as well as anything else (maybe a little worse, see sibling comment).
Another approach would be using a "meet-me" relay with a fixed IP, such as TURN. This also has the advantage of handling NAT on both sides (which would be a common issue with a roaming-to-roaming situation). I can't think of any reason it's impossible to run Wireguard through TURN but I can't find any examples of anyone doing so, likely in part because the TURN client is usually embedded in the application and is a bit complicated. Still, might be a hobby project to implement it for Wireguard.
That said, I do believe both IPv6 and OpenVPN will have this exact same problem - IP change will not be reflected until something forces setup to repeat. The difference would be that these, at least I do believe, will re-resolve on retries. Wireguard doesn't really have a sense of "retrying the connection" which makes it sort of philosophically difficult for it to do so.
Once I move into the network that has the respective VPN endpoint, the subnets that are routable via wg become routable via ethernet/wifi which have higher priority, so the traffic will go directly.