I'm encountering the same problem here. Actually not exactly. It's just that my architecture is susceptible to the same kind of problem (now that I'm thinking about it). I guess what we should do, is store the state of the router (perhaps in volatile state) and consult it, before attempting to request any route. Then if necessary we could either stop the route from changing, or cancel the previous request (and requests should be made through a cancelable utility), before making a new one.
Potentially you could also add a middleware that has ability to cancel an async action at any stage. So you could potentially consult the above mentioned flag on every stage of the action and bail out if you detect a conflict. But that won't stop the request itself.
The third option and the best one I guess, would be to create a little volatile state for every request, with a state and a reference to the actual request, so that it could cancel it automatically on destroy. And destroy will be triggered as soon as you assign a new request to the same node on the tree.