This gets weirder. If you grab the different gate objects, delete and re-plot them (changing their stat index) you get all sorts of different outcomes for the gate going up.
Nice find. Might have something to do with objects being deleted.
EDIT: I see what's going on, looked at a stack trace. Object pointer is pushed onto stack during execution of ExecuteOOP. That function calls PlotTile on the target tile during #PUT. PlotTile calls HarmThing before setting the new tile's properties. HarmThing calls RemoveThing if it's a stat object (and if it's object #0, HarmThing deducts 10 health, etc). RemoveThing, upon completion and if the removed object's index is not the final one, will move all objects in the array back to remove any gaps in the array. When it gets back to ExecuteOOP, the pointer has not been changed, and it is actually referencing a completely different object when it goes to write the CurrentInstruction.
To implement this, it would require a large rewrite to the object garbage collection system. The way it is in ZZT is an ugly side effect of how it uses pointers.
Should this bug be reproduced in Lyon or should code run as one would expect in normal conditions (which is how it is coded now)?