Yeah, in terms of game design, I don't think disabling player input is the way to go. It would feel horrible.

But I've just updated the experimental one. What you found was overlooked. It was technically a bug in the context of the purpose of the AnimationState variant since its point was to eliminate the dipping problem at the cost of multimix and some "snappy" movements. The fix was a minor change: https://gist.githubusercontent.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2/raw/ec10be8fe92900d1dcb6bc22cad0a1e6fa21c803/AnimationState.cs

The buggy behavior was inherited from the multimix version where if a crossfade was interrupted, the mix percent that was completed was inherited as an "alpha" of the animation that's fading-out. This behavior shouldn't have been there in this version. There's one more change on hand that might make it act a better when switching between the same animations. I'll post again on this thread when I apply it.

We are still trying to figure how the multi-mixing behavior should be implemented. This is the ideal for eliminating the unnatural "blinking" into a pose when you spam switch between multiple animations.

But in any case, as a 2D game animator, I do recommend critical and common transitions to actually be short, hand-animated transitions and accomodate those transitiona animations with code. This will often look much better regardless of which animation it was "transitioning from". Just make sure to favor the destination pose and it'll almost always look better than naive mixing. This is the way classically animated 2D games were done. And more recent games with skeletal and semi-skeletal systems like Muramasa and Rayman Legends also do this.