Not really? That would rely on my local devices sharing a subnet with my phone/laptop, and would also blow up in fun ways if I ever got on a hotel wifi that used similar subnets to my home network.

You should pick a random network (like in 10.x.x.x if ipv4) and a smaller mask for your VPN than any public wifi would ever choose. Then a yet smaller mask for your home network. The probability of collision then is tiny.

I don’t think you’re quite grokking the problem space here.

The goal is “I want my phone to always connect to a given hostname. When I’m on my home WiFi, that connection should be direct. When I’m not, that connection needs to bounce through the WireGuard tunnel”.

The target system isn’t even on the same subnet of my home LAN as my phone. So short of injecting custom routes, netmasks aren’t helping me at all. But even if they were, short of running split horizon DNS, I’d need my WireGuard subnet to be a superset of my home LAN, and for my home LAN to be a portion of that, and also my WireGuard subnet can’t conflict with whatever network I’m on. So I’ve now made a bunch of complex constraints and my home LAN is taking constraints from my remote access flow.

Or I just tell WireGuard to route the IP of the LAN-side system and to disable itself if I’m home.

I understand your goal. I've run this solution for more than a decade, originally with openvpn and multiple subnets.

Yes, it does require your local networks to be subnets of the VPN. If you can't control dhcp, then you can add static alias IPs to the local interfaces and thus have "another" local subnet for this purpose. In these cases, the wireguard link might need two addresses (AllowedIPs: 10.x.x.x/31) where one of them is configured on the local interface with the local subnet mask, the wireguard ip configured with the wider VPN mask.

Adding IP aliases doesn't seem to be possible on phones though ...