En passant square in FEN (in UCI)

[Sven]

Therefore not ignoring FEN ep squares even if a pseudo-legal ep capture would be illegal has "functional impact"

I don't think I have understood this. Could you pelase do an example of a test case where we could have an issue ?

I have quickly created a silly example, I don't know whether it is kind of real ... consider this position:
[d]
Black moves 1...f5 which creates the "pseudo" ep square f6:
[d]
Now let's assume you get this position as FEN, and you search (or play on the board) 2.Rb1+ Ka8 3.Ra1+ reaching the following position:
[d]
From here, 3...Kb8 repeats while 3...Kb7 avoids repetition. But since the position after 1...f5 has f6 as ep square but now you have no ep square any longer, you regard both positions as different, no matter how you do the repetition check. While I am pretty sure that no program will really miss to find 3...Kb7 as best move, 3...Kb8 will be searched, too, since the repetition is missed.

I know the example is very artificial but you wanted me to demonstrate what I mean.

I would not call it an issue, just a very minor drawback that almost all engines probably have.

Btw it is not restricted to conversion of FENs only, you have this "problem" each time you detect a potential ep square after making a double pawn step.

Sven

[Sven]

I can even try to make it more "perfect" by adding a white pawn on c6:

[d]

Now searching 1...f5 will probably return advantage for black if the ep square is set to f6 after 1...f5, although White can repeat with 2.Rb1+ Ka8 3.Ra1+ Kb8. While part of the variations will indeed be evaluated as draw (e.g. those after Ka8 if repeated), all positions after Kb8 are seen as better for black, and propagating these values up to the root may destroy the search result.

I hope I got everything right.

Sven

[Sven]

Unfortunately I created a position where Black has indeed nothing better than 1...f5, since after 1...Rcd8 2.Rb1+ Kc8?? White wins with 3.Ba7 (mate in 6). But you may still get the idea

Sven

[smrf]

Dear HGM,

simply find an example for an engine which will fail starting from a traditional chess position using XFEN notation but will work correctly instead using the different FEN notation.

P.S.: your FEN example shows, that there are some more identical positions which might have different representations in FEN. But that also should be reduced. XFEN transforms such differing strings into one unique.

P.P.S..: I just saw your example is nonsense.

[smrf]

... since FEN is the older standard. ...

Well, but it is not consistent. The demand is to represent identical positions (if possible) by one unique FEN string. But this is not always the case regarding the e.p. flag. Thus FEN cannot be the model of choice to handle this special question.