I tried to start working on the rewriting of the move-notation generator and parser in the newClick=1 mode. This is still not based on the AI's move generator, with as a consequence that it is limited to moves with at most a single locust square (which can also be used for indicating unloading the captured piece, when it refers to an empty square, or for castling, when it refers to a friendly piece). AI-based move generation, though, allows an arbitrary number of locust squares, and an explicitly indicated piece for unloading on one of those. Incorrect notation is generated for the new possibilities this offers.

But I ran into the problem that I am not sure how I would want the notation of these moves to look!. The Diagram uses 'Standard Algebraic Notation' for normal chess moves, i.e. ID of the moved piece followed by the coordinates of the destination square, possibly with one or both coordinates of the square of origin in between as disambiguator, if multiple moves matched the simple description. And an 'x' in front of the destination if the move was a capture.

I had already extended that notation for locust captures, by treating the piece as a 'trampler', which first moved to the locust square, and then continued to its destination, fully mentioning both. E.g. Lxe4-e5 for a Chu Shogi Lion on e3 that made a hit-and-run capture of the piece on e4, and then moved on to e5, or Lxe4xe5 if it also captured a piece on its destination.

It seems undesirable to always mention all locust squares when there are many, and omitting those would not lead to ambiguity, because the captures are not optional. E.g. if a Tenjuku Fire Demon would move to h12, burning g12, i12, g13, h13 and i13, the notation FDxg12xi12xg13xh13xi13xh12 does not seem very productive. For one, many other notations could be used for the same move, as the order of the locust victims is arbitrary. So to get a unique notation extra rules would be needed to order the victims, or in absence of those parsing would become more difficult, as the parser would have to handle cases where the order is not how the move generator does it. I'd much rather write FDxh12, as burning is not optional, so that there is no ambiguity is possible with moves (of a Fire Demon) that go to h12 without burning that same set of pieces. In the same spirit as that we don't explicitly mention the victim in e.p. capture, but just fxg6 when white captures f5. It would be a possibility to introduce a new symbol for capture through burning, if we don't consider FDxh12 explicit enough. Like FDx!h12, FDxh12! or FDxx12.

There could be multiple moves to the same square, which imply different locust captures. Such as in the case of two Advancers, on b1 and e1, which could both move to e4. Then one would capture f5, the other would capture e5 in this move. But I would rather disambiguate these moves by (partial) mention of the square of origin (e.g. Abxe4) than by explicitly mentioning the victim (Axe5-e4). Because that is also what SAN would do if there was no victim at all.

In general the principle of SAN is to leave out as much as you can, other than the piece ID and the full destination. For tramplers this would often be convenient. E.g. the Ultima Long Leaper on a4 could jump over enemies on d4 and f4 to land on g4. LLxf4 would unambiguously specify this move; there is no need to explicitly mention d4 and f4, as in LLxd4xf4-g4. I would not go so far as to use the presence of the capture indicator 'x' to disambiguate moves, though: if a Lion on e4 stands next to an enemy on f5, and can move to (empty) g6 either with or without capturing that enemy, I would not want to make this clear by writing Lg6 vs. Lxg6, but require Lxf5-g6 for the latter instead.

So I suppose the rule must be that if there are multiple moves with the same origin and destination, differing in the number of locust captures, all of those should always explicitly mention all locust victims. And the locust squares should always be mentioned in full; no quirks like Lxf-f6 to distinguish the capture of a piece on e5 or f5.

This still does not seem very satisfactory for 'shooters' like the Odin's Rune Chess Forest Ox, which is a Knight that can optionally capture one enemy adjacent to its destination. Moves like FOxe4-f3 for a Forest Ox coming from g1, to contrast it from the noncapturing FOf3, look a bit unnatural, as we don't envision the Ox reaching f3 via the more distant e4. A more intuitive description has the Ox moving to f3, and picking a neighbor to shoot down from there. We could adopt a system for this like is used in International Draughts notation, where the pieces captured by the move are written as a comma-separated list after a semicolon behind the move. Like FOf3;e4. This could also be used for burning, if we adopt the convention that mandatory victims can be omitted from the list. The Fire-Demon move discussed earlier would then become FDxh12; .

That still leaves the issue of pure rifle captures. For a piece that normally is a trampler, such as the Lion, it would make sense to write it as a back-and-forth two-leg move: Lxe5-e4 for a Lion that started on e4. For Rifle Chess itself it would make less sense to always write the redundant return leg. It would be more logical there to just write Rxe7 (for a Rook on e1), and understand from the rules that this implies return to e1. This would make the move notation inconveniently rule-dependent, though. That problem would not exist if another symbol than 'x' would be used to indicate this kind of capture. In fact R;e7 would be a generalization of the shooter notation, where omission of the destination square would imply the piece stays/ends up on its square of origin.

Unloading of pieces is still another matter. Perhaps a special symbol should be used for legs of a move that swap a piece with what was on its destination, like the tilde. So S~e4 could be the move of a 'Swapper' on e2 that 'captures' to e4, and relocates the victim to e2. The Valkyrie of Odin't Rune Chess can relocate a 'friendly victim' to any square on its path, which can be written as a move that visits the unload square virst, and then swaps from there: coming from e1 this could be V-e3~e7 to capture on e7 and relocate the old occupant to e3. I already introduced the symbol ~ for indicating flexible castling, but in that case the destination square of the King is usually empty, so it cannot mean swapping there. (There is the case of a castling where the King ends on the Rook square, though, so perhaps we should introduce different symbols for swapping and castling. Or we could adopt the convention that for pieces that can castle the ~ always means castling.)