AnimationState does indeed special case track 0 here:
EsotericSoftware/spine-runtimesblob/4.2/spine-libgdx/spine-libgdx/src/com/esotericsoftware/spine/AnimationState.java#L215-L216

Also here:
EsotericSoftware/spine-runtimesblob/4.2/spine-libgdx/spine-libgdx/src/com/esotericsoftware/spine/AnimationState.java#L235-L236

It's complex for various reasons.

Setting mixBlend yourself is OK. If AnimationState did the same, I'm not sure it would behave correctly if later an animation was set on track 0. If you know how your application behaves and that setting mixBlend as you are works, that can make sense.

What is the advantage to having track 0 without an animation much of the time? It may be better to rearrange your app so track 0 is used for "base" animations that are never combined with lower track animations (because there are no lower tracks).

The beta won't be considered stable until it's no longer beta. Can't say yet when that will be.

We might backport this fix to 4.2, as it's pretty nasty. I'll check with the team.

You're right, there were a few bugs regarding that! We've fixed it in 4.3-beta.

abuki To mix back to the setup pose, set an empty animation with no mix duration. The note about needing one more frame when mix duration is zero is trying to explain that it will take one more apply to do the mixing out, and then the update after that will be able to "end" the track entry (the end AnimationStateListener event).

You don't normally need to worry about this. You just set the empty animation and continue on as normal.

@abuki Thanks for pointing out the exact misleading passages.

Regarding 1:
Yes, please note that track and track entry may sound similar, but are as different as road and car. An empty car on a road is not the same as an empty road.

This in general applies to all our documentation, we strive to choose the wording as technically precise and short as possible, we never use "approximations" just to sound better. In your case I assume that you missed the important documentation about what the empty animation is, so that might be the main cause (which we are trying to improve).

Regarding 2:
We're improving the spine-unity documentation currently in this regard (it's updated and improved, but not yet final):
https://esotericsoftware.com/spine-unity-main-components#Setting-Animations
https://esotericsoftware.com/spine-unity-main-components#Empty-Animation-and-Clearing
We hope that these changes prevent such misunderstanding and missing important documentation sections in the future.

Agreed, we'll make those changes to the API reference!