The 'kills' data is only valid during move generation. Which is where BadZone() is called to vet the generated moves. Otherwise it is undefined (the data for the latest move that was generated remaining there). Apart from during move generation, BadZone is only called from the Highlight() routine. But when using the NewClick entry system the Diagram should never attempt to highlight the destination of a move that was already suppressed at the generation stage. Perhaps for safety this call to BadZone() should be suppressed when newClick=1; it belonged to the old entry system.

The problems with single/double burning appear to be a case of "works as designed" not being the same as "works as desired". The point is that the heuristic for classifying a locust capture as a shooter (swapping the order of the locust and the destination click) only works for the last locust victim. Any earlier victim will always be treated as trampled, and has to be clicked before the final destination. So clicking destination and then a locust victim unambiguously indicates the single burn, while a double burn first has to click one of the locust victims to trample it. Then it will highlight the destination in cyan,and when you click that you can pick a second locust victim, which completes the move by shooting it.

The way the NewClick system works is that for each move it determines a click sequence required to select that move. Normally this would be the origin, all locust victims in the order XBetza specifies those, and finally the destination. There are exceptions for e.p. capture and castling, which in general require only two clicks even though their move encoding involves more squares. And for shooters, where it swaps the final two clicks. Detecting whether a move is castling, e.p. or igui can only be done during generation of the move, when the move descriptor from which the move results is still known and can be consulted. From the internal encoding of the move it cannot be concluded whether it was a trampling or a shooting; mpafsmpacabW (Forest Ox) and mpafcaW can both move from e3 to f5 while capturing e5, but only the first would be considered a shooter (because the final leg always retraces the one before it) and require click order e3-f5-e5.

I suppose I should put the code that moves the destination click earlier inside a loop, so that it is able to pass locust vctims as lon as the preceding two legs have a cab structure. Then the double burnings could be entered by first clicking the destination, and then picking off the burn victims until you run out of victims, or click the destination again to terminate the move. That would be a much more intuitive way for entering multiple burns.

Some other remarks: You use (af)0 to force a slide on a K atom, but this is not recommended. Because (af)0K is expanded by pre-processing to KafKafafKafafafK..., as if every distance is a separate move, which would be attempted independently. So if the slide is blocked at the second square (so that afK would fail to produce a move) it would still keep trying afafK etc. And when afafafK was a valid non-capture, it would still again check the first four squares for emptiness when attempting afafafafK and longer paths. The equivalent plain Q would do much more efficiently, and probe each square on the path only once, and stop after it finds an occupied one. You can turn the Q into K for the burning by using ya to specify a range toggle. E.g. mpyacabQ would describe a Queen burning one enemy adjacent to her destination.

It is also important to take the replacement victim only on the final leg, and hop over it when positioning for the next shoot, to prevent it being added as a spurious locust victim. I think you already do that.

[Edit] I now uploaded a new betza.js, which suppresses the BadZone() call in Highlight() when newClick=1, to make sure it cannot interfere when kills is not valid. (Flush the browser cache!)