Almost.
I had three very rigourous test routes when I was trying to pin down the nature of RUT.
All of them, involved a route with an additional route point that I could skip. Via/shaping had no effect. All of them had a section of route which was calculated by Basecamp and which was passed unaltered to the XT. But I knew that if the XT recalculated that section, it would choose a different way for the route.
The skip was designed to force the XT to recalculate the route. I had observed on other occasions that a recalculated route behaved differently from one that hadn't been recalculated. My suspicion was that they had used the algorithm for dealing with deviating from a track-trip. I still think that.
In every case, the difference between the two ways was marginal, and I knew where the tipping point was. (The tipping point is the place where if you place the bike on one side, the XT will route in one direction. If you place the bike on the other side it will route in the other direction.
Ok. To answer the question. Every one of those routes was tested after a system a reset. The XT displayed RUT behaviour when the route was shown as "imported". U turns allowed.
I tested all of them by manually modifying the mImport byte. Same route, same behaviour from me. Different result. The 'saved' route performed better than my 590 would have done. In one case giving just one u turn request, and then recalculating the way I was riding. In another case, the recalculation was instant - and a good few miles before the tipping point. One waited until near the tipping point, but recalculated ahead before it reached that point.
So yes, the saved route has always behaved as we think that it should, even when enticed to get stuck in a RUT.
Also - the issue that led to this discovery. On one test I set all of my route points as Waypoints, so that if necessary I could quickly rebuild the route using favourites at the roadside. I expected that I would need that, as I was using the first part of the route for another test. I did need it, and the subsequent test route behaved imperfectly for the first time. In a later test I repeated the same section of 3 mile route 5 times trying different things. I could not get it to show RUT behaviour no matter what I did because I had built the route on the XT. Routes built in the XT never showed RUT behaviour.
It was reporting this observation that prompted someone on here to comment that there were two lists in trip planner - "Imported" and "Saved". Which frank was immediately able to latch onto, because he had been trying to decode the trip files while looking into subclass fields and had already encountered the "mImport" byte.
I had never spotted the two lists - each of my tests started with a factory reset Zumo - otherwise my riding history could be blamed for routing behaviour. I didn't want the Zumo to know that I always turned left at that junction.
BUT I have never done what you described. I just think that if you have loaded a route and then choose the end as the destination - that would be classed as an imported route, and will display RUT behaviour when you deviate.
If it was a 'nobbled' route (mImport byte changed), or one that had been created on the XT, or one that was a 'Where To / Destination' (ie not a route from trip planner), then they will behave like Saved routes and will not show RUT behaviour when you deviate.
So that is my logic. I could be wrong, and if I am, then that is useful information - and I'll modify my mental model accordingly.
And if I am right - well that's useful too, because at the moment it is only what I think will happen. My best guess.
But you have to be wary. Just because the XT keeps asking for U turns, doesn't mean you have a RUT situation. One of my tests was like that. If that is a legitimate faster way to go - taking into account that the XT's algorithm heads for faster roads rather than taking a faster route - then that is not RUT. That is expected.
But if it gives up and navigates ahead around the tipping point, then that is normal behaviour.
You cannot know where the tipping point is unless you work it out beforehand. I did it by trial and error (binary search) Placing the bike at a point and asking it to plot the way to my intended next point. Then another which I expected to head in the other direction.
Then move one point half way towards the other - see which way that goes. Keep doing that until the two points - one heading one way, ine heading the other - are close together. I cheated and did it in Basecamp first so that I knew roughly where the tipping point was, and then had a narrower area to look at on the XT.