@arcbox And thanks for providing the detailed description above, it helped a lot! I missed to mention that before since I was so glad to be able to provide a more helpful description of what is likely going wrong.

@arcbox You can also specify MixDuration for each pair of animations in the SkeletonDataAsset Inspector as described here:
https://esotericsoftware.com/spine-unity#Mix-Settings
And you can set default values for Default Mix Duration at each newly imported skeleton assets in the Spine Preferences, to save you from having to set it to 0.0 for each skeleton:
https://esotericsoftware.com/spine-unity#Spine-Preferences

@arcbox Thanks for getting in touch, this will for sure speed things up.

arcbox The animation in question was being started after the .Complete callback was fired from a previous idle animation.

This is unfortunately a quite ambiguous description. By "was being started after the .Complete callback", do you mean you called SetAnimation (or AddAnimation) from your callback method which is hooked up to the .Complete callback? Or did you set e.g. a bool property and then in the next Update call of your component check this bool parameter and call SetAnimation?

Please where possible share source code, prose text is always prone to being ambiguous or even wrong.

Also please describe in a bit more detail what your transition setup currently looks like, what you want to achive. E.g. "You receive user input or whatever event at any time to start a move-right animation and want to exit an idle animation loop when it's at the end of the animation. There should be mix transition from the idle to the move-right animation of (mixDuration) 0.2 second (or alternatively, no transition at all), starting at 0.2 seconds before the end of idle.

Also note that if you have set a non-looping idle animation and call SetAnimation from the .Complete callback (being at the last frame), you have no animated frames left for the 0.2 second mix transition where idle mixes into move-right. If you don't want any mix transition between idle and walk-right to happen, that's ok, then you usually either set your Default Mix Duration at the SkeletonDataAsset to 0.0 seconds, or at individual animations set trackEntry.mixDuration = 0.0f (at the newly added or set animation, not at the preceding one).

arcbox I just tried using the AddAnimation method to see if queueing it up that way would avoid the problem, and it improved it quite a bit, though it isn't perfect.

Please always describe what you expected to see and what you see instead. We're sorry to hear that it "isn't perfect", but given this description we are left with guessing what could be your problem. As a programmer you would also not like to get an issue report that just says "isn't perfect".

Do you see the last frame of your previous animation too long, are you missing a transition, are you seeing a completely uncorrelated pose for one frame which is neither from the previous nor from the next animation?

It would likely be easiest if you could share a minimal Unity project which shows your problem and send it as a zip package to contact@esotericsoftware.com, and briefly mentioning this forum thread URL so that we know the context. Then we can have a look at whether the animation itself is causing the problems or whether your code is doing something wrong.

arcbox Is there somewhere I can learn more about setting animations in the appropriate time in the Unity update cycle? I assumed queueing them up using the AddAnimation would be an appropriate method.

The following documentation sections are most relevant for animation updates and callbacks:
https://esotericsoftware.com/spine-unity#Life-cycle
https://esotericsoftware.com/spine-unity#Processing-AnimationState-Events
Also, the Spine API documentation is always the go-to reference for how exactly any parameters or method calls affect the skeleton:
http://esotericsoftware.com/spine-api-reference#TrackEntry-mixDuration

Nevertheless, it's usually not that complicated to set an animation and let a mix of the desired duration (or none at all) happen when one animation transitions to another . It would likely be easiest if we have a look at your minimal reproduction project, perhaps your animation code is not the problem.

@arcbox What is missing from your code above is how you're getting and assigning the material mat, but I assume that you're using something like MeshRenderer.material which creates material duplicates. Please see the documentation on Materials why that is problematic:
https://esotericsoftware.com/spine-unity#Materials

As mentioned before, please see the following section what to do instead:
https://esotericsoftware.com/spine-unity#Changing-Materials-Per-Instance

@arcbox Could you please show the code you're using to set the Material _Color property? Please see the following spine-unity documentation section, likely you want to use MaterialPropertyBlock instead of your way:
https://esotericsoftware.com/spine-unity#Changing-Materials-Per-Instance