I don't know if you are doing this, and believe me I know how easy it is to go down this road, but asking yourself why an OTL does not write a 1 to its operand when that OTL's input rung is true is a waste of time; much more useful questions are "what is the state of that OTL's input rung" and "what was the value of that output immediately after the rung with the OTL?"
The tricks to diagnosing problems like this are
(i) to assume the PLC is doing exactly what you are telling it to do in the program logic, and
(ii) to get stupid (as stupid as the PLC), and
(iii) to discard any notion of what you want or expect it to do or think it is doing.
The primary problem is to discover
why it is doing what it is doing (as opposed to what you expect it to do, which never matters); the tricks above, especially (iii), make your diagnosis a deterministic process and make it far easier to discover that
why. For example, once you confirm that those two OTL/OTU instructions are the only way the O:6/2 bit can be written, then your investigation is reduced to those two rungs and a series of binary questions that are relatively easy to answer: will an upload from the PLC give you the same logic (
sans comments) that you think is in the PLC; what are the input conditions on those rungs; are those rungs executing; etc. What diagnostic logic can be added and/or steps be taken to answer those questions?
Once you know that
why, it will be easier to get it to do what you want it to do.
That's the general idea.
As a specific diagnostic, you could write an otherwise unused bit with an OTE on a branch in parallel with the OTL on the latch rung (0008), and write another bit on rung 0009 in parallel with the OTU. Then viewing those other bits tells you a lot about the rung e.g. whether it is running (cf. @OperaGhost's suggestion).
Sidebar: the logic you have added in the two rungs 0008+0009 is a
Start/Stop Circuit pattern, which operates almost identically with the single rung in the image below.
]
