Single Comment

OK, after some thinking, I have decided upon the following notation for
future implementation in XBoard (to allow AI plugins to communicate the
rules to the GUI):

The possibility to drop a piece is indicated by putting the atom '@'
amongst its move. A numeric 'range' put on this atom indicates the depth
of the drop zone, starting at the 'home' rank. Default depth is 1 (i.e.
plain @ = @1, as usual in Betza notation), meaning dropping on the
home-rank only.

Modifiers f, s and b means that drops are only allowed when there isn't
another piece of the same type on the same file, same color (or hyper-color
for more stringent bindings) or board, respectively. If upto two pieces are
allowed per indicated area, the modifier is written twice, etc. This
actually covers all the setup rules for Big Board Chess: own board half
(@5), one Pawn per file (f@5), two Bishops per color (ss@5). Tori-Shogi
Swallow-Pawns would be fWff@6 (excluding the 7th rank where the Pawn would
have no moves), and a Shogi Knight would be fN@7 to exclude the last 2
ranks of the 9x9 board.

Default modality is 'm', for dropping on empty squares. If you can
capture with a drop, 'c' or 'mc' modifiers can be prefixed, as usual.

The modifier 'j' indicates drops on the home-rank are not allowed. So
Crazyhouse Pawns have a j@7 drop: from rank 2-7. This is consistent with
the interpretation that a drop is a move that slides the piece on the board
along a file from home edge, and the meaning XBoard will attach on a 'j'
prefix on B or R moves (for which the usual Betza meaning cannot apply, as
jW and jF are self-contradictory), which is skipping the first square of the slide.
Repetition of the 'j' could exclude more ranks.

Note that the sliding interpretation requires unlimited jumping of occupied
squares to be default for @. But this can be overruled by an explicit 'n'
modifier, which would forbid jumping anything, and thus force dropping
behind your least advanced piece in each file.

Drops that can be executed only in relation to other pieces, such as this
Castle in the Xiangqi variant, are better treated as moves of that Castle,
using Betza 2.0's 'unload' operator: uW-bW would move the Castle to a
neighboring square to unload something (from the hand, as it did not
capture anything before in that move), followed by stepping the Castle back
to its starting point (bW). Similarly Seirawan gatings can be described by
giving every other piece an extra move prefixed by "iuO-", e.g. N(iuO-N)
for the Knight. O means null move, so uO unloads a piece on the square of
origin, followed by a normal Knight move. And the 'i' indicates that only
virgin pieces have that move. No need to involve the drop atom here.