Folks,
I tried this today, and the reason this is happening is there are left over Cab-1 routes in the switches that conflict with the Cab-2 switch commands sent out. Explaining further: there are two ways routes work in TMCC, Cab-1 and Cab-2 modes.
Cab-1 mode works by building the routes in the switch, and only works for ID's below 10. To fire the route in this mode, a "route fire" command is sent to (all of) the switch(s). All switches associated with the route fire; as built by the route building process by a Cab-1. (akin to a train construct).
Cab-2 mode works by building the routes in the Legacy Base and this is done for all ID's 1-99. The routes in the Legacy base are a collection of switches, no route build commands are sent to the actual switch like the Cab-1 implements.
There is an overlap and potential conflict if a route exists in the switch (built with a Cab-1, or random data in the switch as shipped from the factory) and the Legacy Cab-2 fires a switch in conflict with the switch stored route. When firing a route below 10, The Cab-2 sends a route command with Cab-1 protocol, then the switch commands in the Route stored in the Legacy base. This is why slowing the route throw rate fixes the issue, the switch has a chance to finish the action of the route command then the switch command comes in and executes.
This sounds complicated, but implemented for "legacy" products like ASC's or SC2's, so maybe I should just conclude with the way to fix the issue instead of delving deeper into the protocols:
Simply clear the route before building them on Cab-2. Once you clear the route, then build the intended route with the CAB-2, and they should work, no matter the "route throw rate" setting. Instant works fine in my setup.
FYI: The route commands are sent above 10 (10-99) but they are not interpreted by the switches.