@Grelle Glad to hear it fixed the issues on your end as well, thanks for getting back to us!

@Grelle Did you test your reproduction scene with the latest spine-unity package mentioned in my above posting? When trying to reproduce the issue, the GameObject in the bottom line named Resolve_Interruption using the new Match Mix Mode works without any sudden position jumps on my end, while the other two in the bottom line (MixNext_Interruption and AlwaysMix_Interruption) are showing such an issue.

@Grelle No problem . Thanks for sending the package, we'll have a look at it and get back to you here on the forum once we've figured out what's going wrong.

@Grelle We have just pushed some commits (main commit and a compile-error fix on Unity 2017) to officially support this feature. Compared to the intermediate version provided in the zip file in the above posting, the Mix Mode has been renamed from Resolve to Match, and one issue with the first clip's weights has been resolved.

From the Changelog:

Skeleton Mecanim: Added new Mix Mode Match. When selected, Spine animation weights are calculated to best match the provided Mecanim clip weights.

A new spine-unity 4.2 unitypackage is available:
https://esotericsoftware.com/spine-unity-download
The spine-unity documentation will be adjusted soon as well.
Please let us know if you encounter any issues with this new feature. Thanks again for reporting!

@Grelle Glad it helped! We hope to officially add this feature soon, so you can happily upgrade the spine-unity runtime without fear of overwriting these manually replaced files.

@Grelle Sorry for the late reply! The problem lies in the difference between Unity clip weights and Spine animation weights. Unity provides absolute weights of the form result = A*w1 + B*w2 + C*w3 where the sum of all weights w1 + w2 + w3 == 1. Spine animations in the SkeletonMecanim component are applied on the preceding skeleton state with a certain weight, which can be described as result = lerp(lerp(A, B, x), C, y) for the same three animations.

In your blend tree, the order is important when you have three animations and two of them are identical. Close to the end of the transition, the values are as follows:
lerp(lerp(idle, idle, 0.8), right, 0.2) equals lerp(idle, right, 0.2) and is as expected, while
lerp(lerp(idle, left, 0.2), idle, 0.8) equals left * 0.2*0.2 + idle * (1 - 0.2*0.2) which weights left far lower.
When the transition is done, there are no longer three animations but only two, which is then again correct, thus immediately jumping to the correct end result, as you can see in your reproduction project.

I have just added an experimental additional MixMode called Resolve to the Mecanim Translator which calculates the respective Spine weights to match Unity's absolute weights better. While this will not resolve all issues for every possible scenario, it should be a fix for your use-case. It will take some more testing before this feature will be released officially, but I have attached it below for you for testing. Please let us know whether this works for you, and also if new issues arise.

@Grelle We have just released a bugfix for the issue for both the spine-unity 4.2 and 4.1 runtimes.

New 4.1 and 4.2 spine-unity unitypackages are available for download:
https://esotericsoftware.com/spine-unity-download
Thanks for reporting!

The required change is actually just a space added in SpineAttributeDrawers.cs which is needed on Unity 2023.2+, see the commit here.

The problem was that since Unity 2023.2, menu entries can't have both one entry without and one with submenus at the same name:

A
A/B     // this will not be displayed, as A already exists and has no submenus

Issue ticket URL for later reference:
EsotericSoftware/spine-runtimes2556

@Grelle Thanks for sending the reproduction project. We will get back to you here on the forum once we've figured out what's going wrong.

@Grelle If you can reproduce the issue on 4.2 with the latest spine-unity package, please do send us a minimal Unity project which still shows this issue. You can send it as a zip file to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at what's going wrong.

@Grelle Adding the procedurally generated skeleton mesh to the prefab fixes the issue of the prefab always being marked as "Override" (as changed) even though nothing has changed. The meshes are automatically removed before building the executable via a pre-build step, so build size or load time does not increase.

Unfortunately it's a tradeoff and not a perfect fix without drawbacks. See this issue ticket here:
EsotericSoftware/spine-runtimes1273

You can configure the behaviour via the Unity Edit - Preferences - Spine settings, in section Prefabs:
https://esotericsoftware.com/spine-unity#Spine-Preferences