Hard to tell what might be going on just looking at the video. Could you maybe send me a short piece of repro code that I can add to our cocos2d-x example project, including your assets, so I can debug it locally?

Do you see the problem using the Skeleton Viewer?
Skeleton Viewer
If so, likely the spine-cpp runtime is working as designed and if you provide your skeleton JSON then badlogic can reproduce the problem and tell you why it behaves as it does. If it only occurs with spine-cpp runtimes, then badlogic will need code that reproduces the problem.

Thanks, that helped. It was confusing at first, as I see the behavior you described. I simplified the project and then noticed that layer_idle_l_add_block_bl has only 1 timeline (it should have 4 in the simplified project). The export has animation clean up enabled, which removes keys that appear to be unnecessary. If you select your animations and run Clean Up in Spine then you'll see the same behavior in Preview.

Clean Up sees the keys that set the boxing glove color to transparent, sees that the color is already transparent in the setup pose, and so removes the keys that would normally be unnecessary. When playing animations on multiple tracks, special care needs to be taken so keys in the higher track animations are not removed with Clean Up.

Sorry you ran into that gotcha. I suggest not using Clean Up for now. We need to make some improvements so you can design animations for tracks and still use Clean Up. Eg, maybe you can lock a key so it won't be removed automatically, or maybe you can mark an animation for use on higher tracks so Clean Up will adjust the rules it uses to remove keys. I've created an issue to track these improvements:
https://github.com/EsotericSoftware/spine-editor/issues/461

BTW, you seem to be hiding attachments using transparency a lot. Sometimes you need to do this to fade images in/out, but you should know that drawing an image with zero alpha still goes through the GPU and counts against your fill rate (the maximum number of pixels you can draw each frame). It's better to hide attachments when they no longer need to be visible. You can still fade them out, you'd just also set a key on the slot so the attachment is not visible at all once the alpha is zero. Alternatively, if you stick with hiding via transparency, you should make sure that the renderer you are using at runtime checks the slot's color and skips rendering the attachment for the slot when the alpha is zero.

While reviewing your project I found two bugs with ghosting that are unrelated to your problem above, so we have a few other things to fix too! :nerd:

Ah, yeah that has been one of a few slightly unintuitive parts of the Spine interface for a long time. The key icon for attachment visibility is next to the slot, but you change the attachment visibility by clicking the dot next to each attachment.

We have an issue to address the usability of keying attachment visibility:
https://github.com/EsotericSoftware/spine-editor/issues/149
You are welcome to comment on the issue there, though you'll need to sign up for a free GitHub account if you don't have one. With a GitHub account you can subscribe to issues so you receive emails when there is activity, which is nice. Otherwise we can discuss any ideas you have for improvements here on the forum (in this thread or another) and then add them to the issue afterward. The key you might see next to an attachment is to key the attachment's deform (meshes, paths, bounding boxes, and clipping attachments only).

If you haven't found it yet, you can check out our roadmap, which gives a nice high level view of the GitHub issues:
Spine Roadmap