That's why I said the choice is debatable - it's the same number of moves to the target, and it comes down to a preference for defense at the intervening point vs. movement left at the end of the second move. The AI prefers defense (and it likely should only do that in dangerous areas, NOT on home territory, so I agree this may not be the best choice). The actual 'best' really depends on how threatened the unit might be in the area being traversed vs. how useful an extra half movement point might be a turn down the road - there is no universally correct answer. However, the AI is set up to prefer defense universally, so it is operating correctly in terms of the intention of the code. Whether the AI SHOULD prefer defense (or more particularly WHEN it should) is another matter, and one that could probably be tweaked to produce a small improvement (even something as simple as preferring defense only in territory not owned by the unit's owner for instance, might give better overall results, though even then it might behave stupidly during an invasion).
Anyway, I have figured out the bug that causes the definitely incorrect third path. The UI (so strictly when a HUMAN is giving orders) calls the path generation with a pseudo-group that it makes up at the time and consists of the selected units (i.e. - it doesn't use the ACTUAL CvSelectionGroup). In particular it re-uses the object instance that represents this pseudo-group, which means that a cache test in which it checked for the same group it had cached information for (and used object-pointer-equality as the equality test), was using information for the wrong unit. This will be fixed in my SVN push a little later today.
need to make less for my next game.
.)
(Note: children aren't human until they 
