I now pushed a fully debugged version of fairy-move-model.js, and in particular the new cbPiecesFromFEN facilities, to my 'trial' branch. I also made a description of what it can do:

Facilitate definition of 'run-of-the-mill' chess variants

A routine this.cbPiecesFromFEN(geometry, fen, pawnRank, maxPush) is
provided, which will return an object that contains both the
pieceTypes object and promote function that you would have to return
in a game definition. The pieceTypes object is derived from the
provided FEN, which can contain many commonly used fairy pieces.
Such as Archbishop (A), marshall (M), (xiangqi) cannon (X), camel (C),
zebra (Z), elephant (E), champion (H), wizard (W), griffon (G),
rhino (U), vao (V), Shogi Pawn (S, for soldierw/soldierb), Lion (L)
and amazon (T).

The last two arguments are optional, and would limit the board area
where a Pawn can be pushed forward by more than 1 step, and by how
many steps, respectively. The default is that Pawns can be pushed
up to any square on their own board half only when still on the
starting rank (derived from the last white Pawn encountered in the
FEN). For variants with 8 board ranks and orthodox Pawns this default
suffices.

When no other unorthodox pieces are participating than those mentioned
above (all orthodox pieces are of course supported too!), and the
promotion rules are orthodox, defining the game can become extremely
simple. One can just feed the FEN of the initial setup to
cbPiecesFromFEN, and get the pieceTypes and promote values that
the cbDefine function has to return from there.

For example, if we use the function inside cbDefine() as

var p = this.cbPiecesFromFEN(geometry, fen);

the object with piece definitions will be p.pieceTypes. All pieces
occurring in the FEN string will be included in this. The FEN can
represent a board with more ranks than the actually defined board;
in that case only the pieces on the actually existing ranks will
be placed in the initial position as described. Other pieces will
not appear, but their type will be available for promotion.

All mentioned pieces other than King (K) and Pawn (P or S) will be
included in an array p.promoChoice, and a standard promotion function
that allows Pawns to promote on last rank to any of those will be
available as p.promote. If the default choice is not suitable,
one can assign another array to p.promoChoice, and still use p.promote.
Likewise, if the promotion zone contains N ranks rather than one,
this can be achieved by assigning p.promoZone=N.

The piece types defined with the aid of this function will all be
defined with a move graph for their usual move, and a piece value
suitable for an 8x8 board. If this is not desired, one can still
use the function to define them, but alter their graph (or any
other property) afterwards by calling

p.setProperty(name, property, newValue);

(Note that the name used for pawns is diversified by color: 'pawnw' or
'pawnb'.) This can also be used to add entirely new properties.
For adding moves to those the piece got by default we can use

p.addMoves(name, graph);

with 'graph' the graph of the moves to be merged in.

We can also define additional pieces from scratch, by writing

p.addPiece({...});

with the old-style piece definition on the dots. This function returns
the type number of the thus-added piece. If we want to know how many
types we have defined so far, we can find this in p.nr.

Note that the Lion and Amazon are now supported through L and T in the FEN. For the remaining letters I still have not decided. It only makes sense to add pieces that are frequently used, with a commonly accepted move. This sort of excludes quirks like Snaketongue and Ship. I am in doubt about Nightrider; it is well known, but not used very frequently. Grasshopper is well known, but virtually never used. (And Jocly currently does not support grasshopping anyway.) Perhaps the Crowned pieces after all (D and Y?). Or a non-royal King? The Steward (omnidirectional Pawn) also seems a reasonably popular piece.