Wow, that was a frustrating feature to track down…
It seems that if you have multiple trigger actions [in the same prototype/piece] using the built in loop index property, you should be aware that the property belongs to the piece, not the trigger action.
Which means if you use the same index name in each trigger action, your subsequent ones won’t fire, as the exit condition is reached on the first trigger action.
Ouch, haha 
Yes the “scope” of a loop index is the whole piece, which is actually for the good reason that there are plenty of applications where you’d want to have access to the loop index in another trait (e.g. a “Send To Location” trait or something like that). But yeah, ouch!
It actually seems that bottom most trigger traits using a certain loop index property will block/confuse above trigger traits from using the same loop index property, even if they are not triggered at all.
Here is an example I banged my head against for hours:
basic piece
trigger 1, firing 3 times on command AAAA, using loop index Counter starting at 2 with increments of 2
trigger 2, firing 4 times on command BBBB, using loop index Counter starting at 0 with increment of 2
If one runs AAAA first it will assumes Counter=0 in each of the 3 iterations. I guess trigger 2 took control of Counter setting it a 0 and never relinquished it or something. Even if BBBB was not fired at all, I mean.
For the example:
basic piece
trigger 1, firing 3 times on command AAAA, using loop index Counter starting at 2 with increments of 2
trigger 2, firing 4 times on command BBBB, using loop index Counter starting at 0 with increment of 2
I’m guessing that if the loop index counters have different names, they won’t interfere with each other as described, right?
I’m guessing that if the loop index counters have different names, they won’t interfere with each other as described, right?
Right.