Note that there is an alternative for describing a Pushme-Pullyu in the Interactive Diagram. Rather than relying on the dau kludge for describing friendly hopping (which then forces you to separate the move from the cooresponding one that captures, to prevent enemy pieces are unloaded as well), you can use an ordinary p, and use the captureMatrix for forbidding all enemy hopping. (This only works if the piece with Advancer or Withdrawer capture does not make a genuine hop in the same move; it would not work for a 'Cannon Advancer'.) The leg that hits the victim can then get mcpo mode, as the only way to pass over an enemy is then to capture it.
And Advancer would then be mQyafmcpoabQ, or mQ[Q-mcpoK-bK] using bracket notation. Unfortunately the correspondingly simple notation for the Pushme-Pullyu move, [mpocK-bK-Q-mpcoK-bK], does not work (yet?). For technical reasons, the XBetza compiler splits off the c mode from any non-destructive mode (m, p, o) in a non-final leg (because for the destructive modes the victim has to be clicked in addition to origin and destination, or react to hovering in the move diagrams). But it only does that for a single leg. So there currently cannot be a second combination of destructive and non-destrictive modes in a non-final leg, and the second such occurence would have to be split by hand. Like [mcpoK-bK-Q-mpoK-bK][mcpoK-bK-Q-cK-bK]. This could be improved by making the XBetza compiler also look for a second combination to split automatically (so that 4 different moves would result).
If we would allow diacritical symbols amongst the modifiers we could adopt the rule that p' means friendly hopping only. You would then not need to define a capture matrix.
A better simplification could be obtained by introducing a new modifier for 'optional mandatory rifle capture'. Actually, this involves two new concepts. The 'optional mandatory' means youy have to do the described thing if the square occupancy allows it, but can still make the move for all other occupancies. So an optionally mandatory c leg would always succeed, but if the piece at the end of the leg would be an enemy, it must be captured. This would make it unnecessary to explicitly specify all alternatives.
The second concept is doing things without moving, i.e. collapsing a back-and-forth motion to a single descriptor. I am now regretting that I have defined range 0 as an alternative for infinite (so that N0 is an alternative for the Nightrider move NN), because suffixing with a 0 would be an intuitively nice way for expressing 'without moving', and allow a rifle-capturing Rook to be written as mRcR0. Perhaps I can still allow this in the bracket notation without breaking any backward compatibility. Then [mcpoK0-Q-mcpoK0] would be the Pushme-Pullyu move. And if we adopt the convention that doubling of a destructive modifier (i.e. c, d or u) would indicate all other possible occupancies can be done in a non-destructive way this would simplify to [ccK0-Q-ccK0].
Another remark:
If you would write a line shooter=2 behind the Pushme-Pullyu the Diagram would only require clicking of origin and destination square to enter a move, and would remove any victims automatically.
Note that there is an alternative for describing a Pushme-Pullyu in the Interactive Diagram. Rather than relying on the dau kludge for describing friendly hopping (which then forces you to separate the move from the cooresponding one that captures, to prevent enemy pieces are unloaded as well), you can use an ordinary p, and use the captureMatrix for forbidding all enemy hopping. (This only works if the piece with Advancer or Withdrawer capture does not make a genuine hop in the same move; it would not work for a 'Cannon Advancer'.) The leg that hits the victim can then get mcpo mode, as the only way to pass over an enemy is then to capture it.
And Advancer would then be mQyafmcpoabQ, or mQ[Q-mcpoK-bK] using bracket notation. Unfortunately the correspondingly simple notation for the Pushme-Pullyu move, [mpocK-bK-Q-mpcoK-bK], does not work (yet?). For technical reasons, the XBetza compiler splits off the c mode from any non-destructive mode (m, p, o) in a non-final leg (because for the destructive modes the victim has to be clicked in addition to origin and destination, or react to hovering in the move diagrams). But it only does that for a single leg. So there currently cannot be a second combination of destructive and non-destrictive modes in a non-final leg, and the second such occurence would have to be split by hand. Like [mcpoK-bK-Q-mpoK-bK][mcpoK-bK-Q-cK-bK]. This could be improved by making the XBetza compiler also look for a second combination to split automatically (so that 4 different moves would result).
If we would allow diacritical symbols amongst the modifiers we could adopt the rule that p' means friendly hopping only. You would then not need to define a capture matrix.
A better simplification could be obtained by introducing a new modifier for 'optional mandatory rifle capture'. Actually, this involves two new concepts. The 'optional mandatory' means youy have to do the described thing if the square occupancy allows it, but can still make the move for all other occupancies. So an optionally mandatory c leg would always succeed, but if the piece at the end of the leg would be an enemy, it must be captured. This would make it unnecessary to explicitly specify all alternatives.
The second concept is doing things without moving, i.e. collapsing a back-and-forth motion to a single descriptor. I am now regretting that I have defined range 0 as an alternative for infinite (so that N0 is an alternative for the Nightrider move NN), because suffixing with a 0 would be an intuitively nice way for expressing 'without moving', and allow a rifle-capturing Rook to be written as mRcR0. Perhaps I can still allow this in the bracket notation without breaking any backward compatibility. Then [mcpoK0-Q-mcpoK0] would be the Pushme-Pullyu move. And if we adopt the convention that doubling of a destructive modifier (i.e. c, d or u) would indicate all other possible occupancies can be done in a non-destructive way this would simplify to [ccK0-Q-ccK0].
Another remark:
If you would write a line shooter=2 behind the Pushme-Pullyu the Diagram would only require clicking of origin and destination square to enter a move, and would remove any victims automatically.