The autocombat glitch may be partially my fault, depending on what exactly you're talking about. I spent a long time stepping through memory dumps and reverse engineering how the autocombat stuff works to finally find a race condition involving the animation handling -- ref: https://itch.io/t/300782/bug-linux-x86-64-multiple-versions-race-condition-cause...
The animation actually gets run with autocombat, but it's set to a small value. Autocombat can apply all the moves and end the battle, but since the coroutines are interdependent, on a fast machine one thread can terminate before the other is serviced; here, this meant the battle was ended and characters were removed from the arena prior to the animation completing.
My fix does allow the last move to always complete instantaneously without animation, but I wanted to change as little code as possible -- I didn't exactly have a lot to work with. I would advise extreme caution, because 'here be dragons'. Any complete fix that were to work 100% consistently is very likely going to be quite a bit more work than a check here or there: the combat loop code is kind of a mess (though it actually does approximately work) and needs to be fully decoupled from rendering. If it were chunked into an event dispatch model marshalled by the animation handler, any battle glitches would be solved.