The bug in 4T operation that I reference was complicated by the fact that I was using an interrupt handler to detect changes in the torch switch position. Because the bug was occurring in the interrupt handler, I couldn't use Serial.print() to debug it. I spent this morning re-writing the code not to use interrupts, which actually turned out not to be as big a deal as I thought it was, because there were only a few cases where an actual "interrupt" was needed, and the rest of the code could be written as a function call in loop(). In re-writing the code, I found the bug. The issue was that during the "upSlope" behavior, a change in state from not-pressed to pressed should interrupt the upSlope and change state to notWelding. In the notWelding state, a button press initiates pre-Upslope. So pressing the button to interrupt upSlope would basically put us right back into pre-Upslope, because as soon as the code arrived back at notWelding, it noticed that the button was pressed and (correctly) moved into pre-Upslope. As usual, the bug was the code doing exactly what it was told... I re-wrote the code to clear a flag once the button was released after an interrupt, and to only go back into a new welding action after the flag was cleared.