Ah, I was talking about this use case with Nate some months ago before the changes were made.
You're right, the behavior of image switch keyframes (AttachmentTimelines in the runtimes) did change.
AttachmentsTimelines used to be applied every frame, which was terribly wasteful, slow and scaled badly. Now it uses an event-type only-switch-when-there's-a-key behavior.
The old behavior (since it applied every frame) ensured that Track 1 animation Attachment timelines always reliably overrode what Track 0 animation AttachmentTimelines looked like.
The sideeffect of the new change was that the overriding behavior only applied where there are keys. It would obey attachment changes whenever there's a key on any of the Tracks.
I think you're the first one in the forums to describe relying on the behavior but I figured it was a useful thing for some people. I definitely figured I would use it at some point too.
Right now, I can't think of a sane solution outside of actually making some changes to the runtime, instead of editing your Spine project.
But I guess if you think your animations are limited, predictable and simple enough that you can fix it with just a few additional keys, you should go for that for now.
I also can't remember if Nate described a useful solution for this use that I just forgot.
I definitely agree that a Track 1 animation AttachmentTimeline should prevent the same timeline in Track 0 to be ignored. Or it should be an option, at least, since this is how SRT (and color) timelines work.
I wonder about the implementation and if the "systemic fix" could be done without having to change anything in Spine editor.
