With (or before) 0.24.2, Squad has updated the behavior of rocket engines to allow for non-instaneous throttle changes. That is, changing (or cutting) the throttle on engines can take time to have full effect.

The stock engines do not include this behavior, while the KW Rocketry engines do. The stock engines can be made to use this behavior by adding the following lines to the ModuleEngines MODULE of the part.cfg. The specific numbers chosen adjust how quickly the engine increases and decreases throttle.

useEngineResponseTime = True
engineAccelerationSpeed = 1.3
engineDecelerationSpeed = 1.5

MechJeb 2.3.1.0 does not currently include these response time effects in it's logic for executing maneuver nodes, which means it easily overshoots the desired delta-V.

OK, I tried to fix this in the above commit. When you get a chance maybe you could try a dev build and see if it works for you?

This may end up addressing issue #242, as well.

OK, thanks, I fixed it for ModuleEngineFX too (though I haven't tested it; let me know if it actually breaks horribly). We have a lot of code duplication for ModuleEngine/ModuleEngineFX and we should figure out a way to reduce it :/

I did notice the added time needed for spooling doesn't seem to be included in the burn time estimate, or included in when the burn is started.

I don't think this is too important. Long burns will still be pretty symmetrical, while for short burns the timing is usually not very important as long as you're within a few seconds.

This fix doesn't yet apply to non-maneuver-node burns such as the ones done by the landing AP. I'll leave this open for now to remind myself to have a look at those.

Yes, I duplicated a lot of code but the lack of common interface did not help.
Swamp-Ig made an EngineWrapper in KSPAPIExtensions. I could ask him if we could use it without using his whole DLL.
https://github.com/Swamp-Ig/KSPAPIExtensions/blob/master/Source/Utils/EngineWrapper.cs

Build 278 seems to handle ModuleEngine parts with pretty well, even with absurdly slow spool times (0.45), or absurdly high TWR (hacking parts for fun and profit and TWRs of 87!).

ModuleEngineFX parts, however, don't seem to be affected at all. I see considerable overshoot.

I did notice the added time needed for spooling doesn't seem to be included in the burn time estimate, or included in when the burn is started. Can't say I see an easy way to figure this, either. How do you find the point of half-integration of a piecewise exponential function?

Also tested 281 for slow ModuleEngineFX engines, and node executions work great.

I did notice that Ascent Guidance can be a lot less accurate on setting the apoapsis, now. A little test craft with a TWR of 13 and slow 0.45 engines missed a target of 200km, instead hitting 245km. Seems to only really be a problem for Very slow engines. Even then, it's kinda minor.

OK, the one easy place to add awareness of this was the landing AP course corrections. There are still other places that will have problems like translatron or the final descent stage of the landing AP but those are harder to fix, or at least require more thought.

Just tested build 281, and landing AP course corrections work fine with a slow engine. High deorbit burns can be off some, but get corrected just fine.

However, landing can be essentially impossible albeit amusing. With an engine tweaked to a speed of 0.75, the lander is pogo-ing between 17m and 217m for as long as fuel allows. It's rather entertaining, really.