Single Comment

Typically, the GUI and the engine of modern chess programs are well separated, so the way the castling move is inputted really has no impact on the efficiency of the engine.  Modern chess GUIs handling castling in FRC this way only because someone thought it made sense.  And, purely in the context of FRC, maybe it does.  But in the larger sense of supporting chess variants in a unified, intuitive way, I don't think it makes sense at all.  For a game like the capablanca variants with flexible castling, for example, capturing the rook doesn't make any sense since that doesn't tell you where the rook goes, where as simply recording the king-from square and king-to square tells you everything (which, incidentally, is exactly how chess programs handle orthodox chess.)

Wildebeest is icky because moving a king a single space can be unclear whether you mean to castle or simply move the king.  FRC can have this ambiguity also with certain arrays.  In ChessV, I handle this all in what I consider the simple, consistent, intuitive manner.  When castling, you just move the king.  If there is an ambiguity, a dialog box will ask you if you are making a standard move or a castling move.  Prompting the user is not radical, as normal chess programs do this too when you move a pawn to the last rank.

Normal chess programs probably do the capture-the-rook thing because it was a simple fix to a problem with FRC and they weren't thinking in any larger context.  Chess programs basically played no variants at all until some started adding support for FRC and even that was probably added reluctantly in many cases.