Tonight at 23:53 UTC I found the ITF in an unexpected state; already, a possible fix for the issue reported in the second bullet point of the original entry was in place:

• ITF_LOCK was managed by ITF_STATUS (the timeout was reached), but it wasn't in the fallback state (LOCKED_ARMS_IR); this is a second occurrence of the bug already witnessed last Sunday;
• instead, ITF_LOCK was trying to lock the DRMI, but the PR was still misaligned (after tripping); so, a first hypothesis is that the countermeasure that was put in place is too fast and cannot catch the PR being tripped in order to bring it back to the aligned position; in any case, the automation was not stuck, the ITF was not locking the PR being misaligned, but for the same reason the ITF was safe as no big flashes were going around;
• then, I manually asked to realign the PR and the lock could proceed; I could witness the same effect again live at around 23:59 UTC; this was cured in the same way;
• at the following attempt, the lock of the DRMI was successfull and the lock acquisition could proceed; unfortunately, the ITF unlock while trying the handoff of CARM to the IR on the MC (00:03:45 UTC, unrelated to automation); this time, the autorelock correctly put the ITF in the fallback state, LOCKED_ARMS_IR.

The ITF was left in the LOCKED_ARMS_IR state, autorelock disengaged at 00:37 UTC and ITF_LOCK left unmanaged (standard state).