Turns out that the WinBoard beta version (unlike 4.8) at least already always removed the correct Pawn (the one that last moved). I now uploaded (to
http://hgm.nubati.net/WinBoard-AA.zip ) a version that calculates the e.p. square after a Pawn multi-push in a more sensible way (so that for a move to the adjacent file it is on the from-file, and it only gets on the neighboring file for a lateral move of two or three files). This is hard-coded; there is no way yet to define generation of e.p. rights by other pieces through the XBetza move spec in a 'piece' command.
The specification of e.p. capture in the move spec through an 'e' modifier is still very flakey. (But necessary if you don't use the default Pawn move, as pieces with a redefined move without 'e' would not be able to e.p. capture at all.) It turned out that any move of a piece that had an 'e' somewhere in its XBetza move spec would do e.p. capture through ALL its moves that go to the e.p. square, and not just the moves of the type that had the 'e' on it. So a normal Pawn would also be able to e.p. capture with its forward push, even though the 'e' was only specified for the diagonal moves. This did not hurt before, because with normal Pawns it is geometrically impossible to do that. But when a double-push can follow a Knight path, with the e.p. square directly in front of it, both normal Pawn captures and non-captures can reach that e.p. square. The latest version tries to fix this through a kludge: it only does e.p. capture with a move that stays on the same file if the 'e' was on an orthogonal move, and on other moves to the e.p. capture if it was on a non-orthogonal move. (Assuming only a single move type can perform e.p.; a second 'e' in the move spec is ignored.)
What is really needed is to make it explicit in the internal move representation that a move is an e.p. capture, as not every move to the e.p. square is automatically an e.p. capture, and it is very difficult to figure out which are afterwards. The current move representation evolve from the 'coordinate notation' used in engine communication, a concatenation of from-square, to-square and (optional) promotion character. This was extended for handling locust captures by allowing one or two squares to follow the 'promotion character' if the latter is a semi-colon, like e4g5;f4, to indicate where locust captures take place (f4). We could use a similar kludge for encoding e.p. squares, e.g. using an ampersand as promotion character. This requires a lot of changes, as all 'consumers' of internal moves should be made aware of this convention, and take the appropriate action when they detect it.
