I do have a theory though. If AlphaBeta() repeatedly calls itself, it would also call Tinker() repeatedly. This would mean that when kind |= 64 is set, it is never unset if AlphaBeta() decides to do a move that doesn't capture a Lion. That might have something to do with it.
This can be excluded. Moves for each piece are generated by NewInner, which then calls NextLeg (recursively for multi-leg moves), which finally calls StackMove (possibly a number of times if there are sliding legs). NewInner loops over the move-descriptors in the move table for the piece, and clears kind before every entry it passes to NextLeg. So the effect of altering kind could at most extend to all moves generated from the same move descriptor. Which is moves with longer sliding leg.
This was intentional: some bits in kind indicate whether you have passed over a square mutated by the previous two ply, in order to recognize discovered attacks and hopper activations. Lions do not have any sliding legs, though. So each move descriptor would only result in a single move.
If you post a Diagram for which it does not work, I can debug that.
[Edit] For hook movers (which have a sliding non-final leg) this is broken, as the sticky bits remain from one continuation to a different, non-overlapping continuation. The routine NextLeg should save the value of kind before calling itself recursively for the next leg, and restore it afterwards. I will make it do so.
This can be excluded. Moves for each piece are generated by NewInner, which then calls NextLeg (recursively for multi-leg moves), which finally calls StackMove (possibly a number of times if there are sliding legs). NewInner loops over the move-descriptors in the move table for the piece, and clears kind before every entry it passes to NextLeg. So the effect of altering kind could at most extend to all moves generated from the same move descriptor. Which is moves with longer sliding leg.
This was intentional: some bits in kind indicate whether you have passed over a square mutated by the previous two ply, in order to recognize discovered attacks and hopper activations. Lions do not have any sliding legs, though. So each move descriptor would only result in a single move.
If you post a Diagram for which it does not work, I can debug that.
[Edit] For hook movers (which have a sliding non-final leg) this is broken, as the sticky bits remain from one continuation to a different, non-overlapping continuation. The routine NextLeg should save the value of kind before calling itself recursively for the next leg, and restore it afterwards. I will make it do so.