I actually hold the opinion that you can learn things best by doing them, and the triggers given were an example of data collision occurring without waits, hoping that you would test it yourself and see it. However, as you seemingly didn't do it, i'm gonna give an explanation anyway:
Of course, in essence, triggers are processed sequentially. The message queues head is poped and the resulting message processed by invoking every trigger that registered itself to react on said message in a certain order (the order in which they registered, i guess). Data collision of global variables occurs when a global is modified by a trigger in a certain point of execution where a other trigger does not expect the value to be changed and therefor continues to use a now invalid value. A wait function can cause such collision because it suspends the pseudo-thread executing the trigger and allowing others to execute, which may change the variable.
However, waits are not the only thing that might invoke other triggers within the execution of a trigger. For example, Syncing operations typically involve a "hidden wait" while waiting for answers of the other players and will therefor have similar problems. And the other way of interrupting a trigger is what i pointed out:
when you call a native function that creates a new message (such as the KillUnit native that creates a "a unit died" message, or the "issue order" native that creates a "a unit has been issued an order" message), this message is immediately processed (whether or not it is actually posted to the message queue in a SendMessage-fashion, i can't tell, as i never hacked and looked into that part of the game), and as we know, processing a message means invoking every trigger that registered itself to react to that message. And this processing is blocking; the native does not return until the message has been evaluated and dispatched.
In the example given above, i had a trigger that fires on the "a unit dies" event. When T1 fires, it sets its temp global variable to 1 and kills a unit; the KillUnit native invokes T2 which writes a 2 into temp. It then returns to the execution of T1 and causes it to show the value of temp to the player, which at this point is 2.
This is a common mistake, because as your map is growing and getting more systems reacting to stuff like aquires an item, dies, issued an order, enters a region (at move unit natives) etc etc, the amount of triggers executed inbetween can get quite huge, potentially scrambling pretty much every temporary global variable, including things like Integer A and Last Created Unit. It becomes virtually impossible to keep an overview over which temporary variable is still valid after creating a unit, killing a dummy or giving an item to a hero.
This is a little to non-existent problem in JASS, as common use of local variables circumvents this problem. However, for GUI systems, the consequence is that using the same temporary variables for systems and spells will eventually cause hard to find bugs, especially since you can not ask for help from anybody without giving the whole map, as every trigger with a suiting event could be the cause. The naive view of yours will not help you in the long run, and i do not advice anybody to be so thoughtless. When you plan on using temporary global variables, make sure you know about your triggers and which actions might scramble their values. Use (shadowed) locals as often as you can instead.
I am not against temporary variables in general. Of course they are a must have for many things, such as ForGroup actions and to get shadowed locals into if-blocks. But be extremely cautious when using them, because it is NOT that easy as it seems.
