Instead of keying Inherit you can use a transform constraint on the idle_neck bone. This transform constraint will make the neck bone follow the chest bone similar to having it parented to it, but you can then set the Rotation Mix to 0 on the block animation, and rotate the neck so it looks correct.
The benefit of this is that Mix is not a Boolean (only on or off) so it will give you a smooth transition.

Hi, I am said artist. First, THANK YOU for clarifying this. I might have never guessed a lack of an inherit key in a separate animation to the be the cause of our failure. Am I to understand these Inherit keys are global to the entire skeleton, and not just individual animations? It seems that behavior might be inconsistent with other key behaviors, which I rely upon to return to the setup pose when each animation is played. It may also have implications for the Animation Cleanup feature.

Either way, this has been plaguing us for months because it's not something we can test for in the Spine editor nor the Preview pane. Perhaps adding the ability to chain animations in the Preview pane would help us and other developers when these problems arise.

I'd like to explain my choice of workaround for posterity, as all of your suggestions would have worked as well. Adding rotation keys to compensate for inheritance is something I do sparingly, as it's not safe for future animation changes. The transform constraint adds complexity and additional setup time, which is also very useful for the reasons you describe, but requires tree traversal in a file that's already massively complex. Being able to key inheritance is fast, stays within my tree selection, and is animation-safe between revisions. And now I'm armed with the specific knowledge that these keys work differently from other keys.

Thanks again!

Addendum. As I'm going through correcting these keys, I notice they don't support curves. They appear to be locked into linear interpolation, even though the setting is a boolean. Might be worth the Spine team's time to revisit these things.

The inherit keys are instant transitions, like attachment or draw order keys. When you mix from one animation to another, you can only have one inherit mode. This means the inherit mode is "wrong" for one of the two animations during the mix. After the mix the inherit mode is correct for the current animation.

Inherit keys only affect the animation containing the key, they don't work differently from other keys. By setting a key in the other animation, now both animations have the same inherit mode, so mixing between them won't have this inherit mode problem. If you mix to or from the setup pose, which has a different inherit mode, then you'll see the weirdness again.

You can see this happen in Preview. Turn off repeat, then click one animation, then the other.

Transform constraint has the benefit of being able to mix to/from it, but as you mentioned it has more setup and adds some clutter to the project.

You're right that inherit keys should not display interpolation lines between them in the dopesheet, as they are always an instant change. We'll fix that! They display correctly in the graph.

For other instant changes (attachment, draw order, event keys) we provide "threshold" properties like mixAttachmentThreshold. This allows you to control where in the mix to change from the mixing out animation's attachment keys to the mixing in animation's attachment keys. We will likely add a similar property for inherit mode. It will still be instant, but you can control at runtime where in the mix it changes.

Nate Thanks Nate. On a subsequent look at this, I discovered keying Inherit Rotation was unexpectedly adding new bone Rotation keys. This is why it appeared the Inherit keys were linearly interpolated.

My bad.

I should ask: If our animation mix is set to zero in the runtime, but we're still seeing what I describe as "global inherit" behavior, does it imply a bug in the runtime? If the Inherit keys only affect the animation being played, I would expect swapping between animations to reset the inherit values to the setup pose.

The rotation is changed to keep the bone's same world rotation for convenience. I think that's commonly what people want. If we didn't change the rotation, it's somewhat tedious to do the math to do it manually.

The rotation change causes a key to be set if auto key is on.

FCSW_Ben If our animation mix is set to zero in the runtime, but we're still seeing what I describe as "global inherit" behavior, does it imply a bug in the runtime? If the Inherit keys only affect the animation being played, I would expect swapping between animations to reset the inherit values to the setup pose.

The question as it's asked is hard to answer. "Global inherit" isn't defined and isn't standard terminology. Mix duration (zero or non-zero) doesn't affect keyed properties being stuck after an animation is mixed out.

If you apply an animation and mix it out to another animation (which may be an empty animation) then the keyed properties should be returned to the setup pose values after the mix. If they don't, yes, it's a bug.

Note if you use clearTrack or clearTracks or trackEnd then the skeleton will get left with whatever property values it had at that time. Mix to another animation (even if mix duration is 0) to get the setup values.

I setup a runtime test with your skeleton. If I play block and then block_to_idle, I see the inherit mode from block persists. This is a bug and we've fixed in in spine-libgdx just now. It will be ported to the other runtimes soon!

You are, as always, fast and thorough with your customer support and amazing at what you do. Thank you for looking into this!