In IOS, the choice of NAT global address pool (or the choice of none at all to disable NAT) can be based on evaluation of an access list or a route map:
https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/13739-nat-routemap.html
TNSR does not have named NAT pools, just one nameless global pool per VRF (and, I guess, a "twice-nat" pool per VRF). Unfortunately the capability to choose "no pool at all" was lost along with the capability to choose among pools!
That said I hope you will not emulate Cisco's NAT configuration because it's an incomprehensible disaster, especially when VRF are involved.
Some of these configurations could possibly be achieved more simply than Cisco by a feature to recirculate the packet:
interface looppair natswitch
instance 10
interface loopnexthop10
enable
interface looprecirculated10
enable
nat inside
interface outside0
ip address 123.0.1.1/24
enable
nat outside
nat pool interface outside0
route ipv4 table ipv4-VRF:0
route 123.0.10.0/24
next-hop 0 via 123.0.1.2 # no NAT
route 0.0.0.0/0
next-hop 0 via 9.9.9.9 loopnexthop10 resolve-via-attached # yes NAT
Combined with a hypothetical policy-routing feature that could consider source IP in routing decisions this could handle having a mix of rfc1918 and globally-routable hosts behind a single "inside" interface. For example, route source IP 10.0.0.0/8 via loopnexthop10, and route source IP 123.0.20.0/24 via outside0 directly.
It creates a problem that 123.0.1.2 is directly attached to outside0 so, if NAT is wanted for that destination address, it's difficult to ignore outside0's automatically-added direct route. The hypothetical policy-routing(*) feature could fix that, too, by considering ingress interface in routing decisions. Ingress interface looprecirculated10 will use the VRF's ordinary table, while inside0 ingress interface will policy override and send 123.0.1.0/24 via loopnexthop10 at higher priority than the directly-attached route.
Recirculation solves most VRF problems with three simple rules:
outside and inside interfaces don't need to be in the same VRF.
to create or freshen a dynamic translation, the packet must enter a 'nat inside' interface and leave a 'nat outside' interface
to match an existing static or dynamic translation, the packet must enter a 'nat outside' interface. It doesn't matter where it exits because that's not known at the time of translation. However the translation may move the packet to a different VRF before routing table lookup if the VRFs differed when the dynamic translation was created.
The only things missing are:
policy routing
nat static mapping ... route-table outside-vrf
local-route-table inside-vrf
(yes, one could add a "via .. next-hop-table" route to <local address> pointing to the other VRF, but this is not general enough. There's no reason <local address> shouldn't still be reachable directly in outside-vrf. The nat static rule should not have to cast a shadow over it. Also there may be 10 inside-vrfs all having local 192.168.1.1 port 22 listening, and we want to use <external ip> port 2220, 2221, ... 2229 to reach each of them.)
ability to bind 'nat pool' to 'nat outside' interface.
--
(*) Unfortunately if 'via classify <table>' was the syntax planned for policy routing, that syntax may not work intuitively because the directly-attached outside0 subnet route needs to be overriden, not passed through a layer of indirection.
