Single Comment

Well, what's in a name? Whether you call the entire set of possible piece incarnations the piece type, and the sub-set of those incarnations on squares with identical 'properties' a sub-type, or call them meta-type and type, respectively, as I did below, doesn't change what they are and how they behave. We could also have called them macro-types and micro-types, which is pehaps even a better terminology. Normally every macro-type consists of just a single micro-type, so we don't have to make the distinction, and call them both 'the type'.

The Xiangqi Pawn can both be considered a single type, with a move dependent on which side of the River it stands, or a piece that promotes to a new type when crossing the River. These are fully equivalent descriptions, because the network of (type, square) transitions trivially satisfiies the condition that no closed loop alters the type, as the move confines closed loops to a rank. I would't say any of those descriptions is not in strict alignment with the rules.

I admit that having to define a huge set of micro-types with the same image in a Diagram definition is cumbersome and looks kludgy, leading to an ugly and bulky piece table. This is why I suggested to make it possible to define a macro-type in a single piece line, using a list of move descriptors (e.g. comma-separated) rather than a single one. But one would then still have to specify which move applies where (i.e. the micro-type taken on by the macro-type on each square). If they all use the same piece ID this cannot be done through a (board-size) array of piece IDs, as the currently implemented morph parameter does. But this can be solved by introducing a new parameter microTypes, which refers to the moves in the macro-types move list, e.g. through single-letter codes a-z.

The same shorthand notation could be used for the value of this parameter as is now used for morph: incomplete ranks could be completed by repetitions of the given part, and a special symbol for 'same as previous rank' or even as previous two ranks could be defined, while entirely missing ranks could default to the first move in the macro-type's list. That would reduce the definition of the Xiangqi Pawn macro-type to a move list fW,fsW and a following microTypes=b/b/b/b/b for the furthest 5 ranks entirely filled with b = fsW.

For a board as irregular as Storm the Ivory Tower there would probably be no shorthand, and all 90 squares would have to be specified. All macro-types are likely to require the same microTypes array (if you properly order their move lists), though. So it might be useful to also have a shorthand symbol for 'same value as for previous piece'.