Single Comment

H.G.M.: '... there is no way in WB protocol to request it from the engine ...'

This is true also for UCI. I regard this to be a very big weakness, which I have avoided in SMIRF's TMCI protocol, which is unfortunately used by nobody else but your Smirf-O-Glot. 

Because engines using that new FEN and multi-variant approach still have to be written, why not to extend used protocols in this point? A GUI SHOULD be able to ask an engine for ALL possible moves. There is no need for an intelligence for this inside the GUI, because it would not be able to grow with upcoming new variants.

H.G.M.: '... the O-i-h system ...'

Nevertheless I would like to use following convention for stored PGN files: if there is only ONE castling move possible at all, it will be matched by ANY string starting with 'O'. 

The use of different letters e.g. M (Marshal) instead of C (Chancellor) or C (Cardinal) instead of A (Archbishop) should not be handled by the FEN string, but by a new to be defined PGN translation tag e.g. for embassy chess: [translate 'M=C C=A']. This is for showing traditionally translated piece letters (to be used on the GUI and PGN only, but NOT inside FEN). An exception to this is the use of J=Janus, having the special meaning of avoiding any Chancellor. Here it would be necessary to use also an additional tag [translate 'O-O=O-O-O O-O-O=O-O'] because of the unlucky old switched encoding decision inside of Janus.

Thus a FEN string always should use those piece letters with a well defined, preferable traditional meaning: this moment I suggest J/A=Archbishop(N+B), C=Chancellor(N+R), G=General/Gladiator(N+B+R). ANY big piece type MENTIONED inside the INITIAL sent FEN might be used for promotions, additionally all the well known 8x8 and 10x8 standard pieces (but using J would disable C).