During Crysis 2 we had a lot of issues with unreliable navigation. There was no guarantee that a character would carry out the requested movement and end up at the wanted destination. Level designers and programmers didn't really know why things would break and how to fix it. It appeared as a very organic problem. This lead to a lot of ugly error handling logic on all layers - C++, Lua and Flow Graph - which in turn added to the organic nature of the problem. Sometimes it worked, sometimes it didn't. The AI movement system introduced in Crysis 3 solves this by being more explicit. No longer is "something failed, therefore you fail." valid. There has to be a reason for it and that has to be correctly propagated down and communicated.
Prior to Crysis 3 the AI movement code lived in the logical leafs (goal ops) and meant that the lifetime of the contextual movement information, such as style, destination, requester and so on, was as long as that of the goal op itself. That's not good, because when a behavior switch occurred all the information was gone. In Crysis 3, this information is maintained in a central place, and separated from the actual request sent from the goal op. In fact, it's completely separated from the goal op concept. In practice, a movement request could be sent from anywhere and the movement system will handle it centrally. When the requester is no longer interested in the request it sent, it simply cancels the request. This doesn't mean the character will stop immediately and loose all the information, but rather the interest in that request has expired.
Prior to Crysis 3 it was hard to know what was being processed right now and what was coming up. There was no bigger plan and the logic was scattered all over the place with lots and lots of branching. For Crysis 3 we try to separate this spaghetti into blocks of logic. These "movement blocks" are responsible for their own isolated task, such as FollowPath, LeaveCover and UseSmartObject. Many Blocks together in a sequence comprise a Plan, and the Plan is produced by a Controller with a string-pulled path as input. We only scratched the surface of what could potentially be planned, but it will still help us get an overview of where we are in the bigger Plan.
It should be noted that this system was not designed and written for perfection, but should be considered a product of heavy refactoring of the existing code base. It's likely not suitable for all game titles.