Well, to put it this way... the new animation system (Animator) is not suitable for anything generic, at least from everything I've seen. It's complicated to use, it requires a lot of overhead, and while powerful it also makes trivial things incredibly complex.
For example with the old animation setting something to move from point A to point B was a breeze. Record a frame in point A, record a frame in point B. To check if something is playing, do animation.IsPlaying. Once the animation reaches the end, it simply ends (unless you set it to loop).
With the animator... you can still record animation from A to B, but as soon as you hit Play, the animation will start playing endlessly. You then have to go into the actual state machine and define different states instead in order to get it to work as you'd expect. Even so, to check if something is playing, you have to know states by name. So it's not a simple matter of looping through all animation states and checking IsPlaying to see if they are playing. You actually have to know the animation state by name, which means having it be hard-coded in your code somewhere.
To determine if the animation has finished, you could transition to some specific "end" state in the animator, and check your animator to see if it's in that state... but then you'd have to ensure that all animators that are used by NGUI check for that specific state name (read: hard-coded), and that users actually know to set up the transition in the first place...
In other words, it's a goddamn pain in the ass to create a generic system around. This is why I haven't done it yet. There is no clean way of doing it that I saw. Everything that was trivial in the old animation system is ridiculously complex in the new one.
