Okay, thanks to reading up on Asie's
Reconstruction of ZZT and some experimenting with KevEdit I have a much better idea of how conveyors work and break.
Firstly, there's a bug with conveyors and drawing. Conveyors iterate over their neighboring elements to work on starting with the southwest and working counterclockwise around the conveyor. This is the same regardless of which direction the conveyor itself plans to rotate things.
When an element with stats is rotated, ZZT temporarily creates an empty in the tile the stat element was originally in. This causes an issue when you reach the end of that list of neighboring elements where that temporary empty won't be updated with whatever else should have been rotated to that tile.
(The cyan conveyor is clockwise and the purple conveyor is counterclockwise.)
Visually, the two non-green gems seem to disappear when the bomb (or any stat element that can be conveyed) is rotated to these two points. However the red and yellow gems are still there. I have objects in the top left corner of the board endlessly checing #if any red/yellow gem and changing to a Y/N character appropriately. They always read "Y".
The visual error only makes it harder to figure out what's happening visually because while this display bug is happening, the two stats are always being swapped!
Looking at this setup, as soon as the conveyor ticks, the bomb will be moved to the northwest and the lion to the west (but will be made invisible due to the display bug causing the temporary empty to be drawn instead). The two stats will flip. So our cycle 6 inactive bomb will instead be a bomb at cycle 2 with its fuse set to the lion's intelligence value. Similarly, the lion will now be at cycle 6 and with 0 intelligence as the bomb was inactive.
You can tweak these settings around and play with the results. Make the lion cycle 0 and the bomb will change characters to match its fuse but never tick down. (The gem is placed there so the lion doesn't wander away if it isn't cycle 0).
The stat order is actually relevant as the bomb must come after the lion for the swap to occur. Because of this, the swap can only happen once so there's no way to make the two switch brains repeatedly with each orbit around the conveyor.
You can also observe the stat swap with the fact that this can make the first element on the board something other than the player.
Here the swap has occurred, lighting the bomb and making it the first stat. The cyan objects here are displaying Y/N based on the results of a #if alligned check. You can see that the two yeses intersect with the bomb element and not the player element.
Which leads to two things, player destruction, and TFing into a lion.
The player destruction bug is easy enough from this. A lot of ZZT's code assumes the first stat is a player. When the bomb goes off, the player caught in the explosion isn't seen as the first stat and so it's destroyed as a default behavior (which is why you can shoot and destroy player clones as well). The bomb of course is also destroyed and you're left with a softlock if you don't have a spare player in a corner somewhere.
For the lion, an easy setup is this:
For reliability the lion is set to cycle 50 here.
By starting the game like this, unpausing by moving west, the conveyor kicks in before the lion can wander away. The stats are swapped and now the first stat will be a lion. The lion will do its lion thing and wander around pretty aimlessly since its new param1 is going be match the original player's param1 and be 0. Not that it matters if you manually adjust it because it's going to try and seek the first stat which is itself.
Eventually though, the wandering lion will decide to move onto the tile that has a player on it. ZZT will see this as a lion attacking the player and run the player hurt code, which runs on the first stat, which is the lion thanks to the conveyor. Part of that code is to force the first stat to change colors to the player element's default color. Thus you wind up with a white lion. If this happens with a normal player, that cycle 1 lion has a reasonable chance of immediately moving into the player at the start of the next cycle which will be when the actual player is invisible due to the display bug causing it to look like the player becomes a lion rather than a lion becomes a white lion.
Despite being very easy to purposely cause this bug, it ends up being a lot more rare in normal gameplay. It requires the player to be standing on a specific tile adjacent to the conveyor, a pushable stat element to also be on a specific spot, and for it to be a gametick where the conveyor gets to act (cycle 3 for clockwise, cycle 2 for ccw by default). In practice, the lion is going to be moving at cycle 2 and having a hard time getting it to land in the right tile just before the conveyor activates.
Sadly, despite being easy to reproduce by hand, it doesn't seem very exploitable. Swapping stats sounds pretty great, but you can only swap stats with stat elements that can be conveyed, which doesn't include objects (where changing code might be powerful) or passages (where changing destinations might be powerful).
tl;dr - Try not to move southwest of a clockwise conveyor or south of a counterclockwise conveyor: you may die.