Stuttering can be largely fixed in software and should be fixed.
First a mea culpa. The low stuttering threshold in Whisperer is partially my fault. I suggested there was a hole in the protocol that lead to packet loss this was around version 0.34 that it would check the OK after the packet send but not before the packet send so sometimes if it moved to a busy state it would read send the packet, and then become OK after that and eat the packet. I said the correct solution to this was checking before and after the packet send, but I was partially wrong here. The problem is that requests 2 packet sends the back and forth from that is an unneeded delay contributes a lot to the stuttering problem. This would have been better before that correction, it ate more packets but it would have rastered faster. The actual solution is request a status at least 1 time between packet sends and use that status signal as both the pre-packet OK screen and the post packet CRC error check. You would check the status before and after each status signal but sometimes those packets would be the same packet. If it said OK for the CRC check, it’s OK for the busy check, just store that information and don’t double stuff your oreos.
Also, you could write better lhymicro-gl code. This would require, tracking the states a bit better. You need to have the 4 bits of information. X-Forward/Backwards. X-Enable/Disable, Y-Forward/Backwards and Y-Enable/Disable. 
R: Y-Enable, Y-Backwards, X-Disable.
L: Y-Enable, Y-Forwards, X-Disable.
T: X-Enable, X-Backwards, Y-Disable.
L: X-Enable, X-Forwards, Y-Disable.
M: X-Enable, Y-Enable.
So if you want to go diagonal RT you need to those commands to get the Y-Backwards, X-Backwards states, if these are not already set. Then you need to set M which turns both steppers on. If you are in X-Enable, Y-Enable, X-Forward, Y-Backwards and you want to Move T, you must explicitly restate T because Y-Enable must be disabled. This saves a lot of commands in rastering (1/3rd at times). But, a goodly number during vector movements. And since buffering is the product of emptying the buffer before you read new data, less compact code will cause buffer underruns and thus stutters.
There’s a couple other oddities like the states into the S1E commands save the Major-Axis that is activated first and affects things like the jog locations (except in some older Lhystudios boards like the M2 v4 and earlier boards), this affects the jogging moves. And I believe it actively matters with regard to the x-axis and y-axis rastering. I used to think it this mode was uniform but it doesn’t appear to be. And it might affect which end steps during unidirectional rastering.