Possible solution to the sap death bug

to be sure: by "next Sap tick", did you mean "the pending Sap tick [that] will prevent Enemy B from queuing its reactive script"?

Ah, I was not clear there. Yes, that's what I meant.

my best stab at it:
allowing trigger2 to queue our 2nd counter somehow prolongs Batch N, to where a future 3rd counter is now considered part of that same batch alongside Counter #1 -- and where it wouldn't have been had counter2 been stifled, and our queue kept shorter.  that is, if the 3rd counter were put into Batch N+1, it would've been free to execute.  i think the following sequence could result in a wasting of Counter #3:
trigger1 trigger2 counter1 trigger3 counter2 counter3
(where death occurs like halfway through sequence or later)

Since the counterattack queue is processed in between each "normal" attack, the only possible "trigger2" would be special actions or another entity's counter, neither of which can trigger a counter unless the target has died as a result. So in this example, "counter1" would execute with the enemy dead, allowing the full reactive script, including on-death. It would also clear "has died" and "no counter yet" flags, so both "counter2" and any potential "counter3" would be ignored. It seems like the behavior is the same whether 4CA2 is checked or not.

what's coming to mind (relying on memory more than starting from the ground up):
1) monster with a string of consecutive counters (no FEs or FDs between them in script), a non-final (as in, not last in queue) one of those fatally hitting itself.
2) contrasting #1, monster with a string of consecutive counters, 2 of those hitting a different monster, 1 fatally.  this is an example of a present Command 1Fh blocking a queuing.
3) something with a character multi-targeting enemies, multiple or all of them having a counterattack (Command 1Fh) triggered, and then the first acting enemy hitting one that was due to act later?  argh; i thought i'd come up a variant of #1 way back when, but all i can see it accomplishing today is a variant of the more benign #2.  it's possible the memory is from a time where i thought things were more FIFO, so if Monster A expanded its queue (e.g. from hitting itself on a counter), that Monster B's initially-triggered counterattack would run before these additions.

Example One:
1. Enemy A gets hit, queues #1F
2. A's #1F fires, queuing 2 attacks -- 1st hit to itself, 2nd elsewhere
3. Counter1 hits and kills Enemy A, setting 3A56
4. Prepare-Counter routine runs -- since 3A56 is set, attempt to add #1F to queue
5. Without $4CA2, the new #1F is added to the queue.
6. Counter2 fires, prompting another "Prepare-Counter" routine.
7. Since 3A56 hasn't been cleared yet, another #1F is added to the queue.
7b. Note that even if $4CA2 had blocked step 5, step 7 would add #1F here.
8. The first of two #1Fs runs, and is allowed to process, due to 3A56.
9. The second #1F runs, but aborts due to $3A56 and $33FC being set/cleared by step 8.

Example Two:
1. Enemy A gets hit, queues #1F
2. A's #1F fires, queuing 2 attackes -- both hit Enemy B
3. Hit 1 kills B, queuing #1F
4. Hit 2 doesn't kill B, but 3A56 is still set, so it queues #1F, too
4b. If $4CA2 blocks step 4 above, only one #1F will have been queued
5. Enemy B runs #1F, allowing full reactive script due to 3A56
5b. Note that if Hit 2 had been the fatal blow (instead of Hit 1), step 5 is unchanged
6. If a second #1F was queued, it is aborted due to $3A56 and $33FC

I can't think of an example three that would differ substantially from the examples above. I'm still thinking $4CA2 can be removed safely, given my changes above, but it's not necessary to remove it, so I'd just assume leave it in, since it does keep the stack cleaner.

Thanks for taking the time to reply again!