Happy to help.
As a side note, I’ve been thinking about why it works this way and I have a theory on it that might help folks write future macros.
The old priority list castsequence macros used some trickery with the spell queuing system to work.
/castsequence reset=0.3 0,<second spell>
/castsequence reset=0.3 <first spell>
For those, the ‘0’ spells worked because they were a mapping to a usable inventory slot (the old ammo slot I think). With the spell queue system that was in place, all of the on-use calls to the ‘0’ slot were queued along with the real spell for that sequence of the macro (first keypress would send ‘0’ and <first spell>, second would send <second spell> or <first spell> again depending on client GCD, ability resources and how quickly the key was pressed). The server would discard the invalid ‘0’ calls and then execute the actual spell. The only way it progresses through the priority is if every castsequence is being run (and incremented) on every keypress however. I’ve never actually seen that posted anywhere, but it makes sense to me (in terms of how the macros worked).
The /cast seem to function differently as they sometimes stop the macro as it is read from top to bottom on some spells (not quite sure what the criteria is). So, while multiple /castsequences can apparently run, some /casts will stop the macro from processing the next /cast. Other /casts seem to process as normal (since Bloodbath will cast in the macro above, even if Demo Shout is on cooldown and unavailable to cast). I’m not sure if it’s a GCD thing, or if there’s a hidden spell classification that controls whether an ability /cast in a macro will stop the macro or not. My rule of thumb is that if it’s a rotational ability it’ll probably stop the macro in a /cast, but burst or long cooldown abilities likely won’t.
Also, it’s my understanding that they changed the spell queuing system to a faster response time (400ms down to roughly 10ms), and I suspect they limited the on-use inventory slot mapping to just belts and trinkets (since hands can no longer have engineering tinkers), which is why the old priority macros no longer work. I might have to try using ‘10’ or ‘13’/‘14’ instead of ‘0’ on a non-engineer to test that.
TL;DR - The reason my macro works is because all of the /castsequences are being processed on every keypress. They get filtered by client-side GCD (and resource checks) to determine which are actually available, and any that are available to cast are sent on to the server (sequentially, top to bottom in the macro). The new faster, more aggressive spell queue system is able to correctly catch which request came first and queue spells appropriately. This works because I’m using /castsequence with my rotational abilities, and /cast with my long cooldown abilities.
I’m going to test this theory with macros for my other classes. If I’m off base I’ll come back and update this as misinformation.
