First off yes it’s a common issue but it’s origin is with the intent of the design and not as to a solution to the jitter that is occurring as the final pose.
The main issue is when casting for the float values directly from the movement component the required value is not a fixed value as to the current state and can fluctuate but a large margin. If in your blend space the direction value for a backwards run take to be triggered is -180 is extrapolated from velocity the output from the blendspace can and usually does jump around based on the unstable value usually generated by the velocity as it interacts with world space.
This is where it’s know to be a common issue as a blendspace usually does not take into fact world iteration as to the need for a constant change base on direction.
The most common mistake is to mix to different control requirements for consoles, using joysticks and PC’s, using keyboard and mouse, and then triggering state changes based on speed.
Speed is only need where velocity as in a racing game for example is required so that the non-constant state of velocity can be changed but is of no help.
Working with Locomotion however does not benefit from non-stable values like velocity except to track if the player is moving or not as to a value to feed into a blendspace as to the intended output state.
This is where we get into design theory and why questions like this is not easy to answer as an issue it’s really easy to figure out what is causing the issue but not easy to answers as to the design intent.
The most direct answer to the problem, excluding design intent as well as the need for replication, is to directly feed a fixed value into the blendspace as to the intended output.
The most common control for Locomotion is the WASD keys which you can set up with any fixed value you wish in the input table.
They could be
Your blendspace axis would be set up as Forwards_Backwards in the vertical
Left_Right in the horizontal.
With this set up you will be feeding a fixed and absolute value as to the needed state change and not based on the almost at times random behavior of the movement component.