The per-connection-classifier just provides always the same result (match or mismatch) for all the packets belonging to the same connection, because it calculates a hash from source address, source port, destination address, and destination port (a combination of which is the same for each connection). There are cases where it is better not to include some of these identifiers into the hash, but we’ll get to these later.
What action the rule takes if the per-connection-classifier matches, and what other matchers you add to the rule, is up to you. Without connection marking, the typical use is that the rules matching on per-connection-classifier directly assign a routing-mark, which is then used to choose the necessary set of routes (routing table). But the caveat is that if a packet has a routing-mark assigned, routes without any routing mark are only used to route it if none of the routes with that routing-mark matches. As you only have default routes with a routing-mark, they match any packet with such a routing-mark, even if its destination is one of your local subnets.
So either the firewall mangle rules assigning the routing-mark must assign it only to packets which you know will need to be sent via WAN, or you have to override the routing-mark assignment later on using /ip route rule rows. So one possible solution would be:
/interface list
add name=WAN
/interface list member
add list=WAN interface=TTNET1
add list=WAN interface=TTNET2
/ip firewall address-list
add list=local-subnets address=local.sub.net.A/mask
…
add list=local-subnets address=local.sub.net.Z/mask
/ip firewall mangle
add chain=prerouting in-interface-list=!WAN dst-address-list=!local-subnetsper-connection-classifier=src-address:2/0
action=mark-routing new-routing-mark=“TTNET1 ROUTING”
add chain=prerouting in-interface-list=!WAN dst-address-list=!local-subnetsper-connection-classifier=src-address:2/1
action=mark-routing new-routing-mark=“TTNET2 ROUTING”
If nothing at private addresses needs to be reached via the WANs, you can use an address-list of all private IPs instead of al your local subnets, which consists of just three prefixes for this purpose - 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
Regarding calculating the hash only from the local address (the source one in these rules in particular) - some services have problems if different TCP sessions related to the same operation arrive from different addresses. So for a small number of clients who have a short enough path to complain, it may give a smoother traffic distribution to use both-addresses-and-ports; if the clients who eventually experience the issues with these picky servers cannot deliver the information to you efficiently enough, it is much safer to use the same WAN for all connections of a given local user, otherwise the information about these easy to solve problems reaches you in the form of “your service is a (beep), it doesn’t work”. But for just a few local users with different traffic volumes, this approach causes uneven traffic distribution.