For lack of a clearer way to convey it:
[image: 19397974.jpg]
It's not a bug, it's just how the network functions in the OS.
When the traffic tries to leave, it follows the routing table to pick the interface the traffic will leave from. If there is no static route for the other IP, it goes out the default gateway. pf is not yet involved.
As the traffic tries to leave via the default gateway, pf can catch it, and using floating rules, it can redirect that traffic to use a different gateway.
There is no magic "go this way" direction to give a packet before it consults the routing table. Even if a service is bound to an IP on a different interface/WAN, that doesn't mean it will leave that way. If a service is bound to 'any' then for TCP it will reply from the address that the client connected to. If it's UDP, it will usually reply from the "closest" interface, which in most cases is the default route.
So unless you have default route switching enabled (which is still buggy, but mostly works, there is an open ticket, notably it has issues with ppp links), if your default route WAN is down, it will still attempt to send firewall-initiated traffic that way, or if there is no default, the OS behaves badly. Most of that is FreeBSD's fault, though we have tried to work around it over the years.
The NAT is required because, in the case of things like UDP or a TCP connection initiated from that interface, in order for pf to shove it out the other WAN, it needs to have the IP of that WAN applied as it leaves that way. You can't send traffic out WAN2 with WAN1's IP, and it wouldn't come back anyhow because (a) the ISP on WAN2 would probably drop it and (b) WAN1 is down so it can't receive the traffic.