Dyndns does work when you have a say in at least one side of each potential connection, unless you want one of your NATted hosts to also act as a bounce server in a pinch.
But you do not seem to be getting that the use of nftables, for the open-network bounce server, is wholly optional.
ah, okay. Yes, I missed that. So the point of nftables then is just to avoid sending REJECT messages, so it makes it harder to determine what port wireguard is operating on?
Yes, it is my preference: When you drop packets, they stop costing you anything further, where rejecting them generates more work for you. And, you are providing attackers free information that you don't need to.
I am not sure the nftables configuration I have is right... It might permit using my bounce server to forward packets that then appear to come from it, if they happen to mention the right port. I would welcome advice.
After further investigation, I have discovered that dyndns would not solve my problem, because the firewall at one end is especially picky; even zerotier and tailscale admit (grudgingly) that they use bounce servers for such clients.
But you do not seem to be getting that the use of nftables, for the open-network bounce server, is wholly optional.