Introduction
As it is, there seems to be no great deal of information on sigorder. I have experimented with it and productively used it through a combination of iscript and plugins. This post details some of my findings.
As is known, sigorder appears to have many internal functions - it is often called in iscripts by select units (none of which I can name off the top of my head). As of the time of writing, I do not know, in these units, how long the sigorder attribute lasts. However, determining that information is trivial with the use of logs and even using SC's print functions, which I believe A of S T had exposed shortly before he left the SC community. (With that said, I don't think sigorder persists in any of the normal, vanilla-Starcraft specific situations we find it in.)
As such, the information below is reasonably accurate with respect to units that don't normally use sigorder a lot.
Main
In iscript: randomly setting the sigorder appears to have no effect.
HOWEVER: plugins (and by implication, the SC engine) is perfectly aware of a unit's sigorder. The unit struct exposes the sigorder variable (whose bit size escapes me at the moment - either unsigned 8-bits or unsigned 16-bits; trivial to check via examination of the UNIT struct. Most likely u8).
As such, plugins can read and write to the sigorder. Iscripts appear only to be able to effectively write to sigorder.
This I am absolutely sure of.
The potential uses of this is staggering.
If there was at any point you wanted to be able to "detect" a unit's action, all you would have to do is stick a sigorder into that unit's iscript and then read it in a unit loop within a plugin. The value of the sigorder, whether it be 1, 2, 3, or whatever (as long as it is in range of the data type of sigorder), is, overall, irrelevant, except that sigorder 0 can be seen as "ground-state" or "default", and that each value can be seen as a boolean variable (consistent with the sigorder's type). That is, assuming sigorder is an unsigned 8-bit type, there are already 256 boolean values that can used as variables, so long as the modder has basic knowledge of bitwise operations AND, OR, XOR, NOT, etc. and their syntax in C++.
Notes
-Once a sigorder is read by a plugin, it is "safe" to immediately set it back to 0, thereby "consuming" it and preventing it from being manipulated by anything else. If you need to remember that the sigorder was detected, just use another variable in your plugin.
-I recommend using nobrkcode blocks to make certain actions and spell casts uninterruptable to prevent any unspecified behaviours. However, a modder may want to make such an action interruptable by choice.
-The different values for sigorder, from 0-255, each be seen as a specific combination of 0s and 1s. As such, you essentially have 256 boolean variables, which can be used to represent different things. As such, a unit might make use of sigorder 1, sigorder 2, and sigorder 3, whenever it wants the plugin to detect 3 different things (like if the unit has 3 different spells).
Examples
(These implementations have problems that are separate from the actual use of sigorder.)
1)
You want to implement a "poison" effect to an attack. No such similar function exists in SC besides Irradiate (maybe other spells I have forgotten?), but Irradiate has a very specific set of effects and conditions. A rudimentary implementation might entail a "sigorder 1" immediately after an "attackwith 1" opcode (or similar attack opcode).
At this point, the attacker has a sigorder value of 1, which is read in a unit loop of a plugin. Parallel to this, the attacker also has its target's address, which is also verified to be valid by the plugin.
Now, using an array whose indices mirror the unit array, you can store the duration of the poison, and in every frame, increment down the durations in the mirror-array and apply damages accordingly in the actual unit array. (You don't have to use another array that mirrors the unit array - any form of accurate tracking will suffice.)
One problem with this implementation is that there is no way to detect "who" killed the unit if the cause of death was poison, so post-match points cannot be awarded accurately (if such a thing is important to you).
Another is the lack of indication that the poison has been applied (no graphics or label).
2)
You want to implement an "AOE heal" spell. Take a spell like Psi Storm. Give it to your healer. In the correct iscript animation (Psi Storm's default value might be CastSpell) for your unit, set up a basic iscript block such that a "sigorder 3" (reminder: the "3" should be reserved solely for use in the context of trying to cast the AOE heal spell) is used at an appropriate point in the healer's animation (for example, if this spell was given to a Zealot, you might want to make him spin around while he casts).
In the plugin, at the moment you read the healer's sigorder value as 3, the healer should also have a record of its target X and Y coordinates. Use those coordinates to find all nearby units (perhaps with the condition that the units be owned by the healer's player) and increase their health by some amount.
Two possible problems with this particular implementation: lack of max HP detection and lack of graphics. The lack of graphics might be resolved by also using a "useweapon n" opcode right after/before the "sigrder 3" opcode, where n is the weapon ID of a weapon that has been reserved and modified to be used purely for aesthetic purposes. (Whether the graphic will appear at the target point or not is another question: IIRC, such a thing would require a specific weapon behaviour type, which at this moment escapes me.)
