Cannot blend the output of two animation state machines outputting the same animation using filter tracks

[SaracenOne]

Godot version

e010e05

System information

Windows 10, Vulkan, Intel® Core™ i7-8700K, Nvidia GTX 1080 (471.11)

Issue description

This is a somewhat specific instance, but I encountered it actually became a pretty significant blocker for me. If you have a blend tree with multiple state machines outputting the same animation, but using a filter track to one apply that animation to specific bones, one of the animations will not play. This will however work if you're only blending multiple animations directly, it only fails when using state machines. Thought it may have been related to this issue since I investigated it and determined that it seems like it may be related to state machines somehow ending up with the same playback object (#45635), but I checked in my specific example and they do appear to have different playback objects.
Here's a screenshot to demonstrate the type of setup I'm talking about

Steps to reproduce

Import a model with multiple animations, add to a scene, create an animation tree with a blendtree as the root. Create two state machines containing the same animations and make sure they are outputting the same animation, connect the output of those nodes to a blend2 node using a filter mode to ensure it only affects a specific set of bones. When you do this, only one of the animations will play. This will only fail if they output the same animation, if one of the state machines is outputting a different animation, it should work without issue.

If you use examine the MRP, the expected behaviour is that both cubes should be oscilating up and down, but due to this bug, they are not.

Minimal reproduction project

animation_tree_parallel_state_machine_animation.zip

[SaracenOne]

Should also clarify that this problem appears to exist in the 3.x branch too, so I don't believe it is a recent regression.

[SaracenOne]

Also fails with additive nodes using a setup like this

[SaracenOne]

Latest debugging is indicating that the problem might still be down to duplicate animation states. Still investigating

[SaracenOne]

Actually, it may not specifically be the whole state, but rather, track blends.

[SaracenOne]

Further info:
Basically, the way I have this set up is I have two state machines, but they're loaded externally. This means that both state machines share the same instance. Basically though, what is happening is the blend tree with the filters is responsible in the two inputs for setting up which tracks in the animation should be defined by the blend2 node's filter tracks. In a List called 'blends', it writes it directly to the animation node during processing. The problem arises is that since state machine B shares the same instance as state machine A, when it comes to writing the inverse blends for the second input, since both state machines are instances, if both state machines are outputting the same animation, the blend tracks from the first input are overwritten by the second, explaining why they can't run in parallel.

From AnimationNode::_blend_node:
float *blendw = p_node->blends.ptrw();

From AnimationNode::blend_animation
anim_state.track_blends = &blends;

As you can see here, when setting up in the AnimationState List, only the track blends and the animation itself is derived retrived as static data from the node. I think the fix is to make a these mutable lists, but it needs to be done in a way which doesn't introduce overhead.

It is a bug, but I guess quite an obscure one. Any suggestions on what might be the best way to go about fixing it?

[SaracenOne]

#51448
Fix here, but might introduce a performance penalty since it introduces new per-frame memory allocations. Requesting review.

[TokageItLab]

@SaracenOne Can you test #75759 whether it fix this issue or not?

[TokageItLab]

Tested, this bug was not fixed by #75759 and I have confirmed that the bug still exists.