About the FEN: is this really needed? Why would one ever want to have a FEN for a position after the first move?

Really?  FENs are useful.  For example, the CECP setboard command.  I think the fact that ChessV will give you the FEN for the current position or load a new position by FEN in any game to be a useful feature.

[idea!] Why not use a fraction on the full-move counter if you want to do this? E.g. move 10.5 would mean after the first half of the 10th turn of the player on move

I'm sorry, but I don’t like this at all.  Instead of adjusting the side-to-move from “w2” to “w” and then to “b2”, you are going to go from “w” on move 10, to “w” but on move 10.5, and then to “b” and roll the move counter back to 10?  That is not cleaner than my approach.  And my approach is cleanly extensible to Progressive Chess

It seems to me that a Marseillais Chess cannot be implemented without some dedicated code that would be useless in single-move variants.

It is certainly true that allowing multi-move variants requires extra code.  So the goal was to add this capability in a modular fashion that is not specific to Marseillais.  ChessV has Rule objects which can be plugged in to enable various capabilities.  To support this, I made a special type of Rule called a MoveCompletionRule which handles updating the side-to-move when moves are made or unmade.  Every game must have exactly one of these.  Unless you are playing a multi-move variant, you just leave the default in place which just oscillates between white and black.  Other implementations can do more complex things.  The MarseillaisMoveCompletionRule can be plugged into any game – add it to Capablanca Chess and you have Marseillais Capablanca with one line of code.

It should be clear that you cannot judge the legality of a turn before you have seen the full turn

Well, this is what we are discussing... I wish to avoid that complexity, which I consider unnecessary and possibly undesirable, at least for Marseillais.  But you do have one excellent point, which is:

Take the Shogi Pawn-drop-mate ban.

Yeah.  That’s a problem.  I may not be able to avoid this issue long term since I deffinately want to be able to support Shogi.  I think that rule did cross my mind previously and I immediately pushed it to the side so as not to give myself nightmares.  Say, I wonder if Zillions can handle that rule?  I bet it can’t.

The other examples you give, like Paco Shako – are probably not going to happen – at least not unless other programmers start assisting me.  ChessV is now up to 400 files of source code.  It’s a ridiculously ambitious project for one guy in his spare time.  Some things just aren’t going to happen.  Unless I win the lottery.  Or find a wealthy benefactor.

The reason I mentioned QS was because I assumed this would be required to detect the fact that the previous ply exposed the King

That’s not how I am handling it.  One of the messages a Rule object can accept is MoveBeingMade – upon which it can update internal information (in the case of the castling rule or en passant rule), but it can also rule that the move is illegal.  The Checkmate rule handles MoveBeingMade, checks to see if the king is attacked, and rules the move illegal if it is.  And, determining if a square is attacked is also routed by message passing.  Butterfly Chess includes a CaptureByAdvance rule which handles the Advancer’s capture ability.  So the Checkmate rule handles MoveBeingMade, fires off IsSquareAttacked messages, which are picked up by the CaptureByAdvance rule.  So Butterfly Chess has both capture-by-advance and check/checkmate/stalemate without either Rule object knowing anything about the other!  Beyond that, support for Butterfly comes entirely from the scripting language - no C#, entirely plug-and-play. Computationally very inefficient, hence my lousy nodes-per-second, but that’s how ChessV is able to play such a wide variety of games and how I am able to add support for new games very quickly.