To be clear though, the bit stays on because of the nature of OTL/OTU
Yes, I forgot to state that explicitly i.e. that bits driven only by OTLs and OTUs* are unaffected, i.e. left alone, by the pre-scan.
* Or maybe I should say bits not controlled by OTEs
The OSF is not the reason it stays latched.
Okay, I get your point, but this is semantics: the way pre-scan handles OSFs is the reason the bit is not unlatched; i.e. the falling edge of the .TT, from before the mode transition to Program to after the mode transition back to Run, is missed, because the OSF storage bit is cleared by pre-scan.
Pre-scan in AB hardware seems to me to be its own knowledge domain. I found a statement once claiming that it is not a scan
per se, in that the program is not executed as a whole, but that every rung is "evaluated" as false regardless of the logic instructions feeding it; that is perhaps one convenient way of explaining what pre-scan does with bits driven by OTEs, OTLs, and OTUs. However, that approach does not explain all pre-scan behavior (e.g. timers; counters; ONSs; OSRs; etc.). In the end I think the only way to figure out what happens is to read the manual for each instruction (and hope it is right). Pre-scan is an activity that affects the PLC state, but it is risky to think of it as a scan.