As I wrote, the scenario you described, requires a lot of hacking. If you follow the scenario #1 above, but you want to run DHCP server on "LAN" side of bridge, you have to introduce some very smart firewall rules to block any DHCP activity on WAN side of bridge.
You may want to re-think your decision to keep using "WAN" addresses on the LAN side of your router. If you can't trust "WAN" subnet (and you don't as it seems, or else you'd be using a simple switch instead) and you have to run statefull firewall, then NAT is only a minor nuisance ... performance wise it doesn't cause large performance drop as connection tracking (which is NAT's cornerstone) is already done because of firewall ... then it's only minor nuisance of configuring a few port forwards (but you have to deal with them this way or another if you want to have decent firewall). And then NAT is already in the picture, 192.168.0.0/16 are not publicly routable addresses. Indeed you may not have to deal with NAT, your ISP does it for you right now.
If the 192.160.0.0/24 is all yours, then you can still use another IP subnet inside your LAN and configure
netmap-type of NAT ... which creates 1:1 mapping of the whole subnet (both src-address and dst-address properties must have same net mask). That would ease NAT administration but make routing trivial.