Another key point to this is understanding what the OTL is doing. Remember, it is a logical instruction, not an actual coil or contact out in the field. Understand that the tag tied to this instruction only has two states. It is either On ("1"), or it is Off ("0"). There isn't a third state that says it is latched, or a fourth state to say it is unlatched. It is either On or Off, that's it. In other words, there is no distinction between On and Latched On. They are both just a "1" as far as the tag itself is concerned.
Put simply, if the rung ahead of the OTL is true, then the OTL writes a "1" to its tag. Easy enough right? If the rung is true, the OTL goes high. That happens on each subsequent scan of the logic as long as the rung remains true. It rewrites a "1" to that tag over and over each scan of the program. When it is true, there is no difference between an OTE and an OTL. Although, in your case, it will not continuously rewrite a "1" due to the use of the ONS instructions. Which is probably a good thing to include here.
Where misunderstanding sometimes creeps in is what happens when the rung goes false. Literally, nothing happens. The OTL takes no action whatsoever. It no longer writes a "1" to that tag, but it also does not write a "0". It leaves the tag unchanged. So if the tag had a "1", it will remain as a "1". An OTE instruction writes a "0" when it is false. But the OTL leaves the tag unchanged. This is the "latched" effect that the OTL provides. In your example, if one of the other LS_Alarms went true, then it would rewrite a "1" to the tag that already had a "1". So, no impact. The tag will remain with a "1" until something writes a "0" to it.
And of course, drbitboy's comment about the HMI button is 100% valid. Hopefully the logic that includes the HMI button also specifies that it cannot clear (unlatch) the latched alarm if any of the alarm conditions still exist. Likewise, based on the logic that was posted, I would know that I have/had an alarm when the OTL is on, but I don't necessarily know which LS triggered the alarm. Ideally there is logic capturing that as well (if it is important to know which LS caused the alarm).
OG