The documentation may be misleading in this case. As a Unity client, don't think you should be making calls to Animation.Apply or Animation.Mix yourself unless you were making a class at the same level of abstraction as AnimationState (which already does all this and more for you).
In Unity, you're already provided with SkeletonAnimation and SkeletonComponent— these solve some Unity-specific problems, but also already handles and models the most basic stuff. AnimationState is also available to us as a part of SkeletonAnimation.
Normally, for Spine to work, (1) the Spine skeleton objects and atlas/images/slots need to be translated into something the engine can understand (SkeletonComponent component does this), (2) you need to keep track of the amount of time that's passed and the animation objects that need to be applied every frame based on that time (AnimationState class does this.) and (3) you need some way to keep the skeleton and the animation together so you can consistently apply the animation to a specific skeleton (SkeletonAnimation component does this.)
Note the kinda-weird thing: SkeletonAnimation tells AnimationState to apply an animation to the skeleton. If you look at it a different way, it's as if AnimationState not only tracks animation state— like its name suggests— but also applies it to the skeleton. Again, in code, Animation.Mix and Animation.Apply are inside AnimationState. It does these things in your behalf.
If you use these classes but also try to do any of the things these classes already do for you, your extra logic is very likely to get overridden. (If you force the logic to execute later, you might end up with code that works but makes no sense in the object model.)
One thing Nate recommended a few months ago was to modify/make an alternate of/extend SkeletonAnimation.
Again, out of the box, SkeletonAnimation has and manages one AnimationState member which keeps track of time and a Spine Animation which it applies to a skeleton based on the time it tracks. This sort of means IT CAN ONLY PLAY ONE ANIMATION AT A TIME. Or rather, it's only meant to manage and play one animation at a time. Any time it plays two animations, it's for crossfading/transitioning between animations.
But roughly, if you had a SkeletomAnimationTwo class that has and manages two AnimationState members, it can play two animations at a time by managing and applying them separately.
The generic sample code is described in http://esotericsoftware.com/spine-using ... animations
It's a bit simpler in Unity: there are three things you need to do:
(1) add a second Spine.AnimationState member.
(2) initialize that member in Initialize(). Just copy what's done to the first one.
(3) add the corresponding lines for the second AnimationState into UpdateSkeleton() where it says //Apply Animation. pretty much follows the same format as Nate's generic sample code where there's two Update()s and two Apply()s.
And then just use one state to play one animation and the other state to play another.
Do note that playing two animations at once requires you to animate your Spine animations (in Spine editor) in a specific way. While, technically, applying one animation over another is possible, there are many things that can cause it to play in ways you don't intend. This will vary depending on your skeleton setup and animations so you might have to take care of this yourself.
