For the NAT part, it's fairly easy. Normal use would be where router has one IP address set to WAN interface and SRC NAT rule would be something like this one:
/ip firewall nat
add action=src-nat chain=srcnat out-interface=WAN
So whatever packets going out through WAN interface will be NATed to use IP address of that WAN. If there are multiple IP addresses set on WAN interface, then router will select one of them.
However, with routed IP addresses, SRC NAT should look slightly different:
/ip firewall nat
add action=src-nat chain=srcnat out-interface=WAN to-addresses=x.y.z.w
i.e. explicitly set IP address to which NAT should change source address of packets exiting via WAN interface.
One can add quite a few selector properties to NAT rule which narrow down selection, e.g. (original) src-address ... making used WAN address dedicated to certain LAN address (or a group of addresses, depending on configured NAT rules).
Likewise it's possible to pick the WAN addresses in DST NAT rules.
Mind that NAT (both SRC and DST) only really look at NAT rules for packets opening new connection. If connection tracking machinery determines that packet belongs to already established connection, NAT will do the proper thing according to what it did for the initial packets. Which includes return packets for e.g. DST_NATed packets. For example: one WAN address (x.y.z.A) is hosting say HTTPS server, which is actually hosted on a LAN server. However when same LAN server initiatest outgoing connections, SRC-NAT might select different WAN IP address (say x.y.z.C). Nothing wrong with this, it just might be confusing sometimes ...
If all packets with certain dst-address (one of the routed /29 addresses) are to be simply forwarded to downstream router unchanged, your main router needs a simple route such as this one:
/ip route
add address=x.y.z.w/32 gateway=<IP address ow downstream router>
Then it's up to configuration on downstream router to utilize the routed address.
Another possibility, when there's a P2P link between main router and downstream router, is to use /32 addressing of P2P link. In this case it doesn't matter if addresses on both sides of link are anywhere near the same subnet or not. And no special route needs to be configured.
config on main router:
/ip address
add interface=P2Plink address=10.20.30.40/32 network=x.y.z.w # where x.y.z.w is IP address of remote end of tunnel
config on downstream router:
/ip address
add interface=P2Plink address=x.y.z.w/32 network=10.20.30.40 # where 10.20.30.40 is IP address of remote end of tunnel
/ip route
add dst-address=0.0.0.0/0 gateway=P2Plink
The same address can be used for all P2P links on main router side. It can be either some RFC1918 address or router's WAN IP address or one of addresses from /29 routed address space (but that's waste of precious addresses so I wouldn't do it). I'd go with the router's WAN IP address if that one is trully static (i.e. it's not static DHCP lease which might change due to some error on ISP side but address you typed in manually when configuring main router). Consequently the
traceroute to/from downstream subnets looks really tidy and your main router reports with same address regardless the direction of traceroute.
As to the downstream router: personally I wouldn't set the IP address to some loopback interface/bridge. It doesn't help much but can cause some mental problems. So either use it as P2Plink local address (which will make NAT engine to use it automatically) or use it explicitly in NAT (both SRC and DST) rules. The later may come handy if you want to do some funky firewall rules, e.g. management only possible if downstream router is contacted at RFC1918 address (and main router has appropriate firewall filters and NAT rules which block connectivity to/from those RFC1918 addresses). This might get a bit convoluted though.