Generally, blandspaces suck. You get 0 accuracy between 2 states like feet taking super short steps, or dipping above/below ground.
Depending on what you need and how much overhead you want to spend, the proper way to do this is Not to use any blendspace at all. Or if really needed the 1ds for speed variations.
Each animation in an AAA style project will likely have a matching acceleration/deceleration to it (probably recorded with root motion too).
The proper way to set up is to create nested state machines and manually control the entry and exit out of the states, so no actual blending happens ever.
You won’t have situations in which animation Run is playing at a 50% blend with Walk.
Another AAA solution to this is a custom BP node for IK speed / leg distance variation.
The speed node would take the underlying animation and augment rotation of hips to provide a wider step while still utilizing the bone limits. (Careful, the free plugins used to crash the game thread, I went and created my own).
Most importantly, splitting away blendspaces altogether provides other benefits, such as your animations can’t twitch when angles are off unless you code stuff really badly (Walk back in a 360deg. Blendspace and you’ll likely see the twitch).
Being able to have accellerate/decelerate transitions, stop animations, and different point of entries for different animations linked to a different Entry animation. (Say you have a regular jump, but the animation actually starts differently between standing still (a Precision jump; start on 2 feet land on 2 feet), walking jump (a hop in which your leading leg matters. You can delay the jump to match the correct footfall to the transition), or a running jump (similar to walking with the leading foot, but maybe a different/less relaxed contraction before jumping).
This does come to the expense of actual work to set stuff up, and animation.
TLDR: You may think your graph is unwieldy, but if you look at a professional project you may be shocked.