Your video seems to confirm the issue I found. Check the prograde direction - it is very close to -180 or 180 deg. The work around ro prever the spin is to
1) Turn SAS off when the prograde direction is close to this point.
2) Wait until the prograde direction passes this point.
3) Manually repoint to prograde, taking care to ensure the new orientation is both close to prograde and clockwise of 180/180
4) Turn SAS back on to keep the orientation.
The bug does not seem to be triggered by low thrust directly, but you are more likely to cross the critical direction with SAS set to prograde when using low thrust.
I made a fork of the source code to see if I could fix this. So far I have half a fix. Preventing the turn in the wrong direction was quite easy, preventing overshoot is much more difficult - you need to determine the angular acceleration (or whatever the correct term is) to decide when to reverse or switch off torque. I attempted to estimate the angular accelleration by the change in angular velocity between calls, but this was badly under-estimated sometimes. My first try seemed to work fairly well for high moment-of-inertia craft but introduced problems with low moment-of-inertia craft - they would either not rotate at all or spin.
More research is needed to try and find a better way to get the angular accelleration. There is a field/property in Rocket.rb2d called simply 'inertia'. Since there is already a 'mass' property it might be moment of inertia - will need to investigate. Also, there should be a way to get the torque from values in the parts. Once I can figure out the units used it should be possible to get a minimum angular accelleration. Another part that can generate torque is a swivelled engine - it might be possible to calculate this, but it looks difficult. A third way to generate torque is from assymetric engines but SAS cannot control this so I can probably ignore it.
The above looks like it could take too much time. I could try one of the following:
1) tidy up the code to remove the commented out 'overshoot prevention' attempts and create a github pull request (the first time I have tried this) so pixelgaming579 can merge in the changes if he wants to.
2) Alternatively, I could try and package the fork with its tiny fix and post the link here (again the first time I've tried to do this).
3) Wait until I have plenty of time and attempt the complete fix.
Ideas?