just dont use KQkq notation at all?

That would also be possible. But (a) the KQkq seems to be more common (and natural tbh) and (b) the edit from KQkq to rook files is a bit more involved.

I believe in master all FRC books use the KQkq notation.

Out of curiosity, what does fastchess use for the FEN tag in a pgn, say?

b) that makes little sense to me as for DFRC you would need to be able to parse both formats, easier to assume only the file encoding than KQkq

fastchess only uses file encoding

With (b) I meant that the effort for this PR virtually involved sed 's/w.* - 0 1/w KQkq - 0 1/g' on the two DFRC books, whereas the inverse operation would need some chess-aware parsing for all FRC and DFRC books.

I checked Lichess analysis board and python-chess, and both revert to KQkq notation. The latter can be checked by running

import chess

fen = "bbqnnrkr/pppppppp/8/8/8/8/PPPPPPPP/BBQNNRKR w HFhf - 0 1"
print(fen)
board = chess.Board(fen, chess960=True)
print(board.fen())

giving the output

bbqnnrkr/pppppppp/8/8/8/8/PPPPPPPP/BBQNNRKR w HFhf - 0 1
bbqnnrkr/pppppppp/8/8/8/8/PPPPPPPP/BBQNNRKR w KQkq - 0 1

To me KQkq is more natural. Similar to SAN one can stick with the default, unless one has to disambiguate when there are more than one rook on the side of the king that still allows castling.

I guess we were just unlucky that vondele used a tool/script with rook file notation in #31.

PS: As a bonus, using KQkq everywhere also seems to lead to better compression. :)

So it turns out that the X-FEN standard says to use KQkq whenever the outermost of several rooks on one side can castle, and file letters otherwise.

This "strict" X-FEN standard is also used by cdb, by the way. See vondele/cdbdirect#19.