All autopilots doesn't play nice with vessels with unbalanced RCS, which translates vessel along with rotation due to this umbalance and/or glitchy physics - namely BobCat's Buran. It tries to pull out last <0.5m/s of maneuver forever as rotation induces translations, and so chasing down node direction causes this direction to change, it keeps trying to get perfect forever and ignores the fact that maneuver is long missed and it's no longer productive and even counterproductive to keep pursuing it (for example for plane alignments, once you fly away from planes intersection, no amount of thrust applied anywhere will fix the situation, the only way is to wait for next intersection). So there needs to be a way to setup a precision threshold to prevent this from happening - besides there is absolutely no need to be perfectly aligned, difference of <0.02° can be simply ignored.

I've seen this on small craft where the pod torque (maybe combined with structural flexing) results in significant orbital perturbations, so the last 0.5 m/s of the circularization maneuver can never finish since the node direction wanders around endlessly as MJ tries to hunt it. Would have to test with tiny correction maneuvers to see the effect there, but maybe just say "close enough" and declare the node finished if the remaining delta-V is a small enough percentage of the original maneuver and the node direction is wandering? Or for circularization specifically you could bring back the old vspeed->0 PID for the final few m/s.

As far as I understand that is a problem of maneuver node "executer" so it manifests every time it executes a preplanned maneuver, be it created by MJ or the manual one. I think there should be an input field "precision threshold" in maneuver node planner window, so you could specify some sensible value there, or MJ could be made to automatically detect such condition and abort execution. Strictly speaking, this effect is a bug in KSP's physical engine as it's mere presence violates the most basic law of physics - energy conservation principle, but it looks like we're stuck with it for a good while so we'll have to deal with it.

I think you mean 9f9ba53

That I did! :)

Added a tolerance field for the node executor in dfb8115. This should let you tell MJ how close is "good enough" so that you can fix this sort of problem if it starts happening.

Try it out in the next release; I'll close this now.