I’m assuming that MoveForward and MoveRight are “hard wired” to the WASD keys, so that they reflect the current state of the keys and you’re not caching them, etc.
Ok, so here’s what I’m saying. Let’s say that you’re in the Idle state. You tap W so that MoveForward is 1, and the transition from Idle to Start begins. The Start BlendSpace starts to play. While still in the Starts state, you immediately release W so that MoveForward is now 0. MoveRight is also 0. Ok, so now both MoveForward and MoveRight are 0 while you’re inside the Starts state. So both inputs into the OR node are False, which makes the output of the OR node False. That gets fed into the top pin of the AND node. Anything ANDed with False returns False, and so the output of the AND node will always be False, regardless of TimeRemaining. And since the False output of the AND node is fed into CanEnterTransition, the transition is never entered and we stay in the Starts state forever, as long as you don’t WASD again. So this is a problem.
Looking at your state machine, there is no way to go from Start back to Idle without having gone through Locomotion and then Stops. So what you’re seeing, where it looks like it’s going back to Idle, means that either you’re going all the way through Locomotion and Stops and then back to Idle, or it just appears that you’ve gone back to Idle, but you really haven’t, which could be explained if you’re actually stuck in the Starts state longer than you meant to.