Wow, you really dived deep into this. Thanks for the feedback. The 't' in XBoard was a kludge to allow approximate representation of moves that were too difficult to handle correctly, by making it possible to 'round up' the move to something that was doable, in the sense that it would include every pseudo-legal move and then some. That way the GUI would not block the entry of any legal move because it though it was not in the piece's repertoire. And then leave it to the engine to refuse the 'and some', should the user try to play it. (XBoard protocol allows engines to do such a thing.) But this strategy fails when XBoard would think one of the 'phantom' moves was checking the King. Enforcing the checking rule makes it that you have to be exactly right in your moves: if some moves are not supported, you cannot play those, but if extra moves are supported, you sometimes cannot move other pieces because it is imagined this would leave you in check. The 't' modifier was added to make it possible to selectively disable checking by all extra moves, so the latter problem cannot occur.

But the diagram does not test for full move legality; its purpose was to demonstrate how pieces move, and not showing some of the pseudo-legal moves because of checking restrictions only caused confusion. (I later added greying out King moves that directly stumble in check, to get a good representation of slider Kings that cannot pass through check, without obscuring what the pseudo-legal moves of the King really are, to do 'Caissa Brittanica'.) So the diagram does not really need the 't', as it accepts any move anyway, and the harm in highlighting spurious moves would not go away by it. And I did not know any variant that really had pieces that could not capture royals with one of their normal capture moves. So I figured the 't' was not needed.

In case of an 'emergency', there is a work-around, BTW: the diagram script looks for the presence of a user-supplied function

BadZone(x, y, piece, color)

which allows you to veto moves that the Betza encoding would allow. I used this to confine the pieces to their zones in Xiangqi, but it could also be used to veto a move because the indicated piece type cannot capture what is at square (x,y). Or to implement variants with restrictions on what can capture what, of which the 'tame' moves are just a special case. And this does affect the highlighting! (The 'k' I added to make it possible to implement the King-facing rule of Xiangqi, which was borrowed by some western chess variants as well.)

Triple moves are indeed a pain. XBoard supports those now. It would require a lot of messy code. I don't think that 'chaining' like in Paco Shako would be the simplest way to do it. It is definitely also on my wish list.

Custom definition of royal pieces is already possible, though the parameter royal=N . In the most recent version this is even implemented as setting a flag for piece type number N, rather than remembering the value of the parameter. So you can have several such lines in the diagram definition, indicating multiple royals. But since the diagram doesn't take account of the checking rule, there is not much effect of defining something as 'royal'. Only its own moves are then sometimes greyed out. And games like Chu Shogi, which do have multiple royals when you insist on representing Prince differently from King (as kanji pieces would), doesn't really have a checking rule, so that in fact the royals should not lose any moves even when they do stumble into check. The diagram doesn't test for game end.