The intended behavior is that running a new animation of a higher priority will override the influence of one with a lower-priority, no matter which is started playing first. The observed behavior of one track being able to override another at the same priority is an artifact of an addition mistake in the blending logic. What is particularly unfortunate about this bug is that it’s preventing tracks within the same priority from doing a correct weighted blend as was originally intended.
You might be wondering now if there is a way to preserve this current, incorrect, but relied-upon behavior. Unfortunately, there are a few reasons it needs to be fixed. One reason is that it’s very confusing and breaks the contract that we publish regarding Enum.AnimationPriority. From AnimationTrack | Documentation - Roblox Creator Hub
Where two playing animations direct the target to move the same limb in different ways, the AnimationTrack with the highest priority will show. If both animations have the same priority, the weight of both tracks will be used to combine the animations.
For track weights that nicely sum to 1.0, the above statement actually holds true. But when the weight sum exceeds 1.0, incorrect things happen. Existing developers may just see this failure to do what is promised on the tin as how things have always been, but imagine that you’re brand new to Roblox development, and you want to blend two tracks. You give two tracks the same weight, and the same priority, start them both, and what you see is only one of the animations play 
. Basically, the bug results in two animation tracks not having the same evaluation priority, even when the developer has explicitly assigned them the same priority.
If you happened to want the second track you started to stomp over the first… you get what you want. But what if you actually want two or more tracks to do a weighted blend, like for an 8-way motion controller? Well, it’s currently possible, but only if you write code to manually manage the track weights to sum to 1.0, by adjusting all the tracks’ weights any time one is started or stopped. Developers who want the correct, intended behavior have voiced their opinion that this is quite tedious to implement. And indeed it was never meant to be this complicated, and in fact doing this kind of manual weight management generates an undesirable amount of animation event traffic.
The second, less obvious reason this bug has to be fixed is that it puts huge constraints on our animation system, and we need to scale the system’s performance to higher player counts and more sophisticated animation blending setups. Preserving the playback-order priority would lock us in to requiring that animation start/stop/weight events always be replicated in such as way that guarantees their ordering on all clients. Otherwise, different players would see different tracks being overridden. This preservation of event ordering can be a bottleneck, and it’s the type of constraint that you want to avoid in a real-time client-server system, whenever possible.
There are more reasons, like having competing explicit and implicit priorities makes for unreadable and error-prone code, and also because one optimization we’re doing to speed up the animation system is to reverse the order in which tracks are evaluated. They are currently evaluated from low to high priority, but the optimal way is from low to high priority, since this allows skipping the evaluation of lower-priority tracks that we know (after evaluating the higher ones) won’t contribute to the end result.
All that said, It is definitely possible to do jumping with different arm animations. The standard way is to group tracks by priority like this:
Core: Roblox animations
Idle: Character Idle animation loops
Motion: Walk, Run, Swim, Jump, etc… often a weighted blend between multiple tracks
Action: Tool use, weapon swings, other top priority animations meant to play over idle and motion.
The most common setup is for the jumping to have Motion priority, and the arm movement to have Action priority. That’s how most developers do things like running and jumping + weapon and tool arm actions. But, it’s technically possible to do it all within one priority, just cumbersome in that you’d likely need to either divide up animations into upper and lower body, with no overlap (not recommended).
If you don’t use Roblox default animations at all, it frees up the Core priority for developer use. This lets you essentially shift everything down, so that Idles are now playing at Core priority, and you have either two levels or motion or action at your disposal.
One last option we will consider, is to add more levels of priority. I don’t know the history behind why there are just 4 enumerated priorities, but I see no obvious reason why this could not just be any integer, removing this limitation altogether. We’ll discuss internally and see if there is some magic solution to this that would save you having to republish all those animations.
