You've probably already thought of this, but the "movement budget" could maintain a residue - e.g. your first diagonal would take 1.4 or 1.5 "moves" (so you'd need speed 2+), your second diagonal in a turn would use the leftover (so you'd only need speed 3+), etc.
There'd still be edge cases around e.g. difficult terrain or talents that consider "standard move" and "boost" movement differently, I admit, but those ought to be pretty minor?
It does create complexity and additional calculation at the very least. That's assuming you're past the conceptual stage that is generic enough not to create a ton of corner cases. The pathfinding phase is already the most heavy loop in the game as far as I can tell, and going with alternate calculations can push that calc time up significantly. Which means that it would need to be optimized, which requires a higher skill floor and possibly delving chunks of the game out of the core scripting functions into custom C++ code. Donald Knuth says premature optimization is the root of all evil, but also that you DO need to optimize that critical 3% of the code that really needs it. I think it isn't clear yet that my pet peeve here should be part of that 3%, or that even if is, if the time is ripe for the optimization pass. EDIT: Forgot C# is also a choice in Godot. And probably a better one in a turn based game.
