Preliminary waitless lag testing complete, again using the "micon-error off-13x blizzard" macro. Not super comprehensive, but when I'm seeing no measurable additional delay over the standard queue in my initial simple worst-case test - 36fps @ >600ms (+270ms delay added to both sending + receiving packets) - I don't think there's a lot of merit to turning more dials for the sake of more complete but non-illuminatory data.

I'm mildly surprised, but I shouldn't be in retrospect - I already know the server gives the client an excessively long leash with what it considers valid with regards to ability casts and the GCD from the tools and exploits that exist in the wild.

That said, this is still only passing a basic "not actively detrimental when used as a 1:1 button replacement" test. My other concerns with more convoluted macros remain, as well as the dilemmas that can't be solved with data alone like the negative interactions with slidecasting and the fact that any double presses/mashing will bite you. Used correctly, you aren't likely to lose casts or suffer a GCD delay... but "used correctly" is a phrase doing some extremely heavy lifting there.

For the curious, potential vectors for continued investigation and/or slack methodology issues:
- are waits affected differently? logically this seems very unlikely given that everything else in macro resolution is handled clientside, but...
- i'm timestamping on chat message receipt (to pick up both /echo and casts in the battle log) - sniffing packets directly would be more precise but more tedious
- not a "real" lag scenario, but i'm confident that it was behaving reasonably accurate to lag in the wild. someone with more time could probably get a more accurate real-world test by running from NA on OCE