Thanks. The question wasn't out of personal experience, just curiosity about which circumstances might cause misfire detection to be triggered and if they exist, what approach one should take to avoid it, or if detection has to be deliberately disabled during LC/NLS activation

Don't recall where it was, but that's the same thing gt-innovation said when I asked about this - ME7-s are not a problem, but some MED-s may or may not complain. I guess it all depends on the misfire detection algorithms which with sensitivity growing with sophistication will cause trouble.

Yes its not bad what you have gathered, and also nice you try to do it out in the open. Ok, compliment mode off.
You can not log or view custom ignition angles in ZWIST (or any other variable for that matter) if you place them in ZWOUT. That is because they never passed through there. You change it right at the end of the chain. But if you log ZWOUT and see the number, you can be sure actual follows this.
That is what we have been telling you, but you seem to like the sightseeing tourist tour approach  
let me help you:
Ok, all fine up to here. But then you totally screw things up!

Read it, think about it and understand where the error is.

Advanced version of this:
To make the function more flexible, you can change the hardcoded number and place either a flash location (extp #8Ah, movb rl4, byte_8A1234 for example and place your editable angle there). Benefit of this is you place the value somewhere safe, where people dont accidentally write the wrong parts of the code.
You can also make a seperate lookup function for 2D or 3D and have the result end in custom ram adress 0x381234. Then you can use this ram adress in your code (extp 0E0h, movb rl4, byte_381234). Benefit of this approach is you have a variable that will be calculated from a map, conditions etc.

On my original, everything worked when I tested it.  zwgru dropped, zmnms also dropped.  Zwopt was high and zwist and zwout followed each other.  Im thinking if I drop zwist, zwout would follow.  A lot like how the overrun fueling stuff needs a change to zwopt to retard the timing. That said a simplification over the original seems like a good idea.

I also understand the ram location write, I just did the constant because all the maps i did were the same throughout, so a constant was fine.  And the constant can be addressed through an xdf.

-20 degrees is ridiculous too, there will be no combustion with that amount of timing retard at all.
So what you'll end up with is timing oscillating rapidly between -20 and whatever comes in from the maps if you do it smart (RPM hysteresis lockout), and if you do it stupid, then the engine will just die the moment you enter LC mode.

Play with a standalone ECU with ALS/LC on an actual car to understand how it is implemented and what sane values are.
At least write the specification of the algorithm down of what you're trying to do before starting to mess with code.

Ok, so after everyones suggestions, this seems to be what Im after.  Change zwgru to -10 (will need revisions and maybe a map) and disable kr.  Nothing else. 

ROM:008A4000 als_kr_disable:                         ; CODE XREF: sub_872D1C+90P
ROM:008A4000                 extp    #0E0h, #1 ; 'a'
ROM:008A4004                 movb    rl4, B_alsflags
ROM:008A4008                 cmpb    rl4, #0
ROM:008A400C                 jmpr    cc_NZ, kr_disabled
ROM:008A400E                 bset    b_kr.14
ROM:008A4010                 jmps    87h, loc_872DB2
ROM:008A4014 ; ---------------------------------------------------------------------------
ROM:008A4014
ROM:008A4014 kr_disabled:                            ; CODE XREF: ROM:008A400Cj
ROM:008A4014                 jmps    87h, loc_872DB0
ROM:008A4018 ; ---------------------------------------------------------------------------
ROM:008A4018
ROM:008A4018 als_zwgruset:                           ; CODE XREF: sub_89DA90+E6P
ROM:008A4018                                         ; sub_89DA90+F6P ...
ROM:008A4018                 extp    #0E0h, #1 ; 'a'
ROM:008A401C                 movb    rl6, B_alsflags
ROM:008A4020                 cmpb    rl6, #0
ROM:008A4024                 jmpr    cc_NZ, als_zwgru
ROM:008A4026
ROM:008A4026 stk_zwgru:
ROM:008A4026                 movb    zwgru, rl4
ROM:008A402A                 jmpr    cc_UC, zwgru_ret
ROM:008A402C ; ---------------------------------------------------------------------------
ROM:008A402C                 movb    rl4, #0F2h ; '='
ROM:008A4030
ROM:008A4030 als_zwgru:                              ; CODE XREF: ROM:008A4024j
ROM:008A4030                 movb    zwgru, rl4
ROM:008A4034                 jmpr    cc_UC, zwgru_ret
ROM:008A4036 ; ---------------------------------------------------------------------------
ROM:008A4036
ROM:008A4036 zwgru_ret:                              ; CODE XREF: ROM:008A402Aj
ROM:008A4036                                         ; ROM:008A4034j
ROM:008A4036                 rets

This good?

I need to quit working on this code when I'm tired... Stupid mistake. 

I am after late ignition timing for a rally style bang bang antilag instead of a spark cut antilag.  Everyone keeps saying that using an ignition angle of -10* is too much but the typical rally style antilag runs timing in the -35* to -45* range.  They also employ a throttle kick to maintain airflow and enrich the mixture to cut down on egts.  (This would be in a system active, vehicle in motion, no input on throttle situation)  As far as timing that negative shutting the engine down, it doesnt make sense.  If you fire the spark when the piston has begun its down stroke it minimizes torque input but keeps the primary combustion event in the cylinder, valve, manifold area.  The spark cut versions dont fire any spark and they dont stall the engine.  They push the fuel to wherever it can find an ignition source, be it manifold, turbo, or exhaust from an alternate cylinder.  The goal is to have bang bang antilag as an option when I put the turbo restrictor in.