If you ever just need a basic setup and DON'T WANT your animations to inherit changes from previously played animations, use this FANCY NEW AnimationState.cs!

Copy this file and replace the AnimationState.cs file in your Unity project with it.
https://gist.github.com/pharan/77c8ab0880c33716acb8

It handles resetting with or without mixing and removes the need to think about/manage which keys should be where and which animations should have which keys (this is admittedly a bit difficult to do at the moment, especially when you have lots and lots of bones, slots and other items in your animations).

If you have opinions on that matter, please chime in below with a reply! Do you think it should be default? What about the people who don't want the behavior? What setup do you use? Does this work with your project or not?

NOTE TO NEW READERS:
This post originally had an old recommendation which people were talking about below.
That simple script has since been replaced with the AnimationState replacement above. Please disregard the conversation below regarding mixing.

Random words so this thread is search friendly:
Preventing skeletons from inheriting the poses from previously played animations.
animation stuck previous
Auto-reset Autoreset SetToSetupPose

This generic Autoreset isn't guaranteed to work when you have mixing.

I just looked into why, and the fix is ambiguous— there are a bunch of ways to go about it, both on the code side and on the animation data side.
I'll look into how it's supposed to work.

The short explanation if you're curious— and I encourage anyone to take a quick look at how this generic "Autoreset" works— is that the autoreset just tells the skeleton to refer to the setup pose and revert all its parts to it. This is done when a new animation starts. (AnimationState.Start).
The problem here is that after the new animation starts, the previous animation is still adding its changes and nothing is going to remove it.

Right now, the guaranteed way to make mixing work is to make sure all the keyed items in the "previous" animation are also keyed on the "next" animation. I know it's a bit complicated to do in the editor but there doesn't seem to be a way around that right now. But what you definitely shouldn't do is key everything. NEVER do that.

I mean don't key all bones transformations and slots and images and everything. That will slow down your game.
You can key all the things you already animated in other animations. That's perfectly fine.

I've looked at the code closer and I think the most appropriate solution to this (without completely destroying all the other runtimes) may be to make "specialized" versions of Spine.AnimationState.
But "specialized" may be a misnomer because I think yours is a common-enough use case that we should at least take care of it.

Good news. We have a functioning AnimationState version that handles your case (assuming your case is simple enough).
https://gist.github.com/pharan/77c8ab0880c33716acb8#file-animationstate-cs

Read the readme here: https://gist.github.com/pharan/77c8ab0880c33716acb8

This should remove the need for the animator to figure out which keys should go where and what to key and what not to key.
Theoretically, as long as it looks ok in Spine editor, the crossfade/mixing should work fine in this version of AnimationState.

I assume we'll be discussing this over time with Nate/Mitch regarding the suitability of its parts or whole to the rest of the runtimes in the future.

That's a good catch. We need those.

But can you describe your color animation setup? Is the setup pose alpha = 0? and where are the keys? Can you share a screenshot of the dopesheets?

I'm not sure what's going on. What's the color in setup pose? is this the before-animation? What are each of those keys doing?

I think I know what the problem is. I don't think it was the color.
This will supposedly be fixed in v3 (attachment overriding).
But the current fix is to open Animation.cs, look for this line: https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-csharp/src/Animation.cs#L451

And comment that out.

Nate's in the middle of updating AnimationState for all runtimes and he's almost done with that part.
He thought the functionality was a good idea so he added it to the list of new features, along with reinstating AttachmentTimeline's old track-override-friendly and mix-friendly behavior.

Likely a different API than the one I stuck in there— possibly going to be a TrackEntry setting instead of a bool on the AnimationState. I'm not sure if he's decided on what to go with yet.

Either way, it's a significant change (you can see some of them already in AnimationState.java) so we'll have to wait til we finish porting.