It's 10% better to retrace its steps than to just say in place, so it oscillates back and forth, retracing the last segment of its path. This happens if it's for example on a highway and the goal is way down below, a GoalYLevel so it's all equal heuristic, so backtrack cost favoring is the tiebreaker.

Actually having a very difficult time reproducing this...
https://youtu.be/tqiSSsoZYLw?t=12m22s

I think I know what's happening here... through chunk caching, it realized it had to make a large backtrace and new route. However, it cutoff that backtrack at the chunk load limit. Then, the next path it calculated was right back to where it started. It didn't continue the backtrack and around because it was better to just go for the easy heuristic improvement.

I don't know any easy way to fix this =/

Maybe with the new movement cost verification lookahead in PathExecutor it might be safe to disable chunk cutoff but leave static cutoff? That would fix this...

With 462ccad (using the estimate from calculation phase) I think it's actually safe to disable load boundary cutoff. That should solve a ton of issues and recalculation woes.