Actually it is Suicide/Giveaway that has no checking. In Losing Chess the checking rule does apply, and you lose by checkmating or baring the opponent. So the situation you sketch is not entirely hypothetical. But fortunately engines like to search captures first anyway, so it would be very easy to stop when you reach the captures if the bestScore is no longer -INF (or the legal-move count is non-zero), in variants with mandatory capture.
I have gone through the alphabetical index A-D systematically to see which variants could be handled by the Interactive Diagram. For very many of those, some programming was involved in the form of user-supplied routines for interdicting some moves ('BadZone()'), or forcing type changes ('WeirdPromotion()'). The latter also because the Diagram does not support location-dependent movement rules, but uses the kludge of changing the piece type (often 'invisibly', i.e. to a type with the same image and same ID) to alter the move.
As requiring user-supplied JavaScript severely resticts the user-base, I would like to avoid the need for that as much as possible. So I have been looking for alternative ways of specifying what BadZone() or WeirdPromotion() should do, which can be supplied as Diagram parameters, from which the general Diagram script then would construct the required functions BadZone and WeirdPromotion to implement it. (E.g. by using a table-driven standard function for it.) This is mainly an interface problem: how can you specify what needs to be done without resorting to Turing-complete programming languages?
The rules for which I had to provide custom JavaScript mostly fell into two categories: "something happens when you reach a certain square/zone", and "something happens when you make a certain capture/move". That 'something' then usually was changing piece type, terminating the game, or forbidding the move.
As a result of this reconnaisance mission, I already implemented a morph parameter that can take care of the majority of 'to-square-triggered' events, through which one can supply a FEN-like description of the board to indicate an event to happen when a piece of the type it applies to reaches that square. Which can be 'declare illegal', 'declare immediate/delayed win', 'change into type ...' or 'offer the standard promotion choice'. Note that game-theoretically declaring a move illegal is the same as specifying it as an immediate loss for the player who makes it.
The other case is still unsupported (or partly supported in an unsystematic way, such as all the anti-trading options). The Golem business also falls under 'capture-triggered event'. I guess a good solution for this could be to have a parameter through which the user can specify a 'capture matrix' of N rows and N+1 columns (where N is the number of participating piece types), rows separated by slashes in FEN-style. The options per square could be change into a piece of a given type (capitals for color of the mover, lower-case for the enemy color), 'declare illegal' (iron or relative iron), 'declare win' (royalty). Iron and royal are really two sides of the same coin, (game-termination, but with opposit result), so it is not surprising that these can be handled in a unified way.
E.g. for Golem Chess (piece types PNBRGHK) the value of this capture matrix would be
- P N B R G H KP . . . . . h . .
N . . . . . h . .
B . . . . . h . .
R . . . . . h . .
G . . . . . H . .
H . . . . . h . .
K . . . . . h . .
where the first column of the matrix specifies what happens on a non-capture (e.g. for pieces that morph every move, like in Kyoto Shogi). To keep the size of the parameter manageable several shortcuts could be introduces, like a number for specifying a number of repeats of the previous symbol (implied to be . when there was none, the 0 being reserved for indicating 'kamikaze capture'), a double-quote for repeating the entire previous row (which would reduce the Golem matrix to 5h/"/"/"/5H/5h/").
With a special symbol for 'illegal' (like !) such a matrix can be used to specify absolute or relative ironness, or a Stratego-like pecking order. Absolute royalty could also be specified this way (e.g. by #). Unfortunately conditional anti-trading can collide with morphing, as under some conditions the move would still be allowed, and it should be specifiable what happens then. This could be solved by adopting the convention that symbols representing such rules (capture of protected, counterstrike) do not define a new matrix element, but apply to the preceding one. If counter-strike was represented by =, and capture of protected by %, the special rules of Golem Chess could have been specified by the matrix 5h=/"/"/"/5H%.%/5h%.%/5h= .
The same symbols could be used in the value string for the mateExemption parameter to indicate which anti-trading rules can be broken when there is no alternative legal move. I guess this even could be used for King Succession when the matrix is extended to 2N+1 columns, the final N columns for friendly capture. Then you would put a Betza move udU on the King that would allow it to 'capture' any friendly piece by teleporting to it, but unload it on the square it came from. You would forbid that move in the King's row of the capture matrix for all friendly piece types other than Prince. Under normal conditions you would also like to forbid it for Prince, but suspend that latter restriction in case of checkmate. To be able to specify such a selective suspension, there should be two different symbols for indicating 'illegal'. E.g. ? and ! . King x friendly Prince would then get ?, King x any other friend would get ! , and you would add mateExemption=? .
Actually it is Suicide/Giveaway that has no checking. In Losing Chess the checking rule does apply, and you lose by checkmating or baring the opponent. So the situation you sketch is not entirely hypothetical. But fortunately engines like to search captures first anyway, so it would be very easy to stop when you reach the captures if the bestScore is no longer -INF (or the legal-move count is non-zero), in variants with mandatory capture.
I have gone through the alphabetical index A-D systematically to see which variants could be handled by the Interactive Diagram. For very many of those, some programming was involved in the form of user-supplied routines for interdicting some moves ('BadZone()'), or forcing type changes ('WeirdPromotion()'). The latter also because the Diagram does not support location-dependent movement rules, but uses the kludge of changing the piece type (often 'invisibly', i.e. to a type with the same image and same ID) to alter the move.
As requiring user-supplied JavaScript severely resticts the user-base, I would like to avoid the need for that as much as possible. So I have been looking for alternative ways of specifying what BadZone() or WeirdPromotion() should do, which can be supplied as Diagram parameters, from which the general Diagram script then would construct the required functions BadZone and WeirdPromotion to implement it. (E.g. by using a table-driven standard function for it.) This is mainly an interface problem: how can you specify what needs to be done without resorting to Turing-complete programming languages?
The rules for which I had to provide custom JavaScript mostly fell into two categories: "something happens when you reach a certain square/zone", and "something happens when you make a certain capture/move". That 'something' then usually was changing piece type, terminating the game, or forbidding the move.
As a result of this reconnaisance mission, I already implemented a morph parameter that can take care of the majority of 'to-square-triggered' events, through which one can supply a FEN-like description of the board to indicate an event to happen when a piece of the type it applies to reaches that square. Which can be 'declare illegal', 'declare immediate/delayed win', 'change into type ...' or 'offer the standard promotion choice'. Note that game-theoretically declaring a move illegal is the same as specifying it as an immediate loss for the player who makes it.
The other case is still unsupported (or partly supported in an unsystematic way, such as all the anti-trading options). The Golem business also falls under 'capture-triggered event'. I guess a good solution for this could be to have a parameter through which the user can specify a 'capture matrix' of N rows and N+1 columns (where N is the number of participating piece types), rows separated by slashes in FEN-style. The options per square could be change into a piece of a given type (capitals for color of the mover, lower-case for the enemy color), 'declare illegal' (iron or relative iron), 'declare win' (royalty). Iron and royal are really two sides of the same coin, (game-termination, but with opposit result), so it is not surprising that these can be handled in a unified way.
E.g. for Golem Chess (piece types PNBRGHK) the value of this capture matrix would be
.....h../.....h../.....h../.....h../.....H../.....h../.....h..
representing
where the first column of the matrix specifies what happens on a non-capture (e.g. for pieces that morph every move, like in Kyoto Shogi). To keep the size of the parameter manageable several shortcuts could be introduces, like a number for specifying a number of repeats of the previous symbol (implied to be . when there was none, the 0 being reserved for indicating 'kamikaze capture'), a double-quote for repeating the entire previous row (which would reduce the Golem matrix to 5h/"/"/"/5H/5h/").
With a special symbol for 'illegal' (like !) such a matrix can be used to specify absolute or relative ironness, or a Stratego-like pecking order. Absolute royalty could also be specified this way (e.g. by #). Unfortunately conditional anti-trading can collide with morphing, as under some conditions the move would still be allowed, and it should be specifiable what happens then. This could be solved by adopting the convention that symbols representing such rules (capture of protected, counterstrike) do not define a new matrix element, but apply to the preceding one. If counter-strike was represented by =, and capture of protected by %, the special rules of Golem Chess could have been specified by the matrix 5h=/"/"/"/5H%.%/5h%.%/5h= .
The same symbols could be used in the value string for the mateExemption parameter to indicate which anti-trading rules can be broken when there is no alternative legal move. I guess this even could be used for King Succession when the matrix is extended to 2N+1 columns, the final N columns for friendly capture. Then you would put a Betza move udU on the King that would allow it to 'capture' any friendly piece by teleporting to it, but unload it on the square it came from. You would forbid that move in the King's row of the capture matrix for all friendly piece types other than Prince. Under normal conditions you would also like to forbid it for Prince, but suspend that latter restriction in case of checkmate. To be able to specify such a selective suspension, there should be two different symbols for indicating 'illegal'. E.g. ? and ! . King x friendly Prince would then get ?, King x any other friend would get ! , and you would add mateExemption=? .