all starting to come together....
https://crt.sh/?id=5059423735
(as background: this is all just to make browsers happy as they don't know the underlying connection is e2e wireguard already)
I have some similar infra at home and I'm quietly scared of the upcoming esni changes that may make my small hack need to turn into a big mess. Did you cover that part?
ESNI was replaced by Encrypted Client Hello (ECH). It relies on the new HTTPS record type which isn't broadly supported yet. It shouldn't end up being that hard to deploy but software largely doesn't support it yet. It's still somewhat useful even without a shared server IP.
HTTPS record type is also used to announce support for HTTP/3 to use it for the first connection, since it's not TCP-based and can't use the transparent ALPN-based approach of HTTP/2. It's also meant to be an optimization by sticking A/AAAA in same record with the other stuff.
My solution in this space of "my browser works properly with walled garden services" also solves for, in some cases, non-walled services, wherein the same endpoint that handles the acme challenge forwarding also has a path the drops out to splice(2) after initial routing
It's this spliced part that I think will be most affected, but I'm also not yet sure (haven't read enough, which is most of why I'm afraid it'll make a mess), if it's also going to make the acme dance indirection harder