chess.com features can't read pgn's where abbrev. pawn capture notation is used

As in topic, what is funny Arena GUI can't deal with that either. Quoting (about notation):

"Captures
When a piece makes a capture, an "x" is inserted immediately before the destination square.

[...]

Sometimes a multiplication sign (×) or a colon ( : )is used instead of "x", either in the middle (B:e5 ) or at the end (Be5: ). Some publications, such as the Encyclopaedia of Chess Openings (ECO), omit any indication that a capture has been made; for example, Be5 instead of Bxe5; ed6 instead of exd6 or exd6 e.p.

When it is unambiguous to do so, a pawn capture is sometimes described by specifying only the files involved (exd or even ed). These shortened forms are sometimes called abbreviated algebraic notation or minimal algebraic notation."

To check, I prepared PGN (with standard headers [Event "?"] and so on...) and moves:

1. e4 e6 2. d4 Nc6 3. Nf3 Ne5 4. de5 Bc5 5. Nc3 Nf6 6. Nd5 Nxd5 7. Bd2 Ne3 8. fe Bd4
9. Be2 d5 10. ed6 *

Trying to put that into analysis for example ends in message of invalid position (not move). After modyfing 8. fe Bd4 to 8. fe3 Bd4 it's accepted. There is only one capture possibility so it is unambiguous. Later 10.  ed6 (en passant) without e.p. as not obligatory is fine regardless of three takes by "e" file pawn possible, but there d6 square have to be specified, but not in earlier case of 8. fe - meaning obviously 8. fe3 - there is no other possibility.

The PGN specifications require the use of x on captures. I don't know this for certain, but I would imagine that support of alternative ways to notate moves, outside the specifications, is unlikely.

Hmm, that's strange - it is very common to use ":" (colon) instead of "x" (at least here), so why it was not provided in spec ? Indeed if 6 ... Nxd5 is replaced by N:d5 it generates same error, but in that case it's not even "x" thing cause: "fe3" notation works (without any "x"), "fe" don't and if "x" is added to form "fxe" it changes nothing, still error and it says (in Polish it means "position is invalid, there can be only one king of each side, side on move cannot be able to take opponent king"), not "invalid move in PGN" or something like that:

Nie można załadować pozycji, ponieważ jest ona nieprawidłowa. W każdej pozycji musi znajdować się dokładnie jeden król każdego koloru, a strona, która ma się ruszyć, nie może mieć możliwości zbicia króla przeciwnika

Additionaly did another test, instead replacing "x" in 6 ... Nxd5 with ":" to N:d5 just removed it (making it Nd5) and it was accepted, in analysis it autoturned into Nxd5. Obviously "x" is not needed, just don't like colon or file(s) described only pawn captures.

The invalid message can mean the position is actually invalid or it can't parse the PGN. So, based on your testing, it looks like the code may strip invalid characters. Nd5 and Nxd5 would both be valid moves, in general. The pawn capture moves would appear to require x, which is still part of the specification.

Well, I don't know about that. I already wrote and shown parser don't require x - as long as is given whole destination square i.e. "fe3" is accepted and correctly transformed to "fxe3", given only involved files (i.e. "fe") fails. Both Standard: Portable Game Notation Specification and Implementation Guide and wiki Portable Game Notation talks about "x" when it's capture, but nothing about it being mandatory. Both say Standard Algebraic Notation (SAN) is used in movetext section. There (in SAN desc.) in "Captures" section (which I quoted earlier) are described cases of using multiplication sign or colon to mark capture as well as "abbreviated algebraic notation or minimal algebraic notation" in case of pawn captures.

About message - it more seems can't parse PGN. Partially as a joke I checked if parser is case sensitive entered that two PGN's into analysis:

[Event "?"]
[Result "*"]
[SetUp "1"]
[FEN "8/2p3k1/8/1P5B/8/8/8/4K3 b - - 0 1"]

1. ... Kh6 2. Bf3 c5 3. Bc6 *

[Event "?"]
[Result "*"]
[SetUp "1"]
[FEN "8/2p3k1/8/1P5B/8/8/8/4K3 b - - 0 1"]

1. ... Kh6 2. Bf3 c5 3. bc6 *

It turns out it works OK - differentiate these cases good. Anyway, I still don't like ignoring other notation forms - it has not to originate/be computer generated, but from human created notation.

What's funny, move capital letters and/or hyphen are not accepted at all. Failing even when there is no ambiguity, ignoring possible move store form - even some programs can write it that way, but you can't put it directly into PGN. Made another sneaky/tricky test:

[Event "b or B takes"]
[SetUp "1"]
[FEN "8/8/7k/1p1b4/1p6/3b4/2P5/4K3 w - - 0 1"]

{ forms 1. C2C4 B5xC4 or 1. C2C4 B5xc4 or 1. C2-C4 b5xc4 or even 1. c2-c4 b5xc4 are not accepted }

1. c2c4 b5xc4 (1... B5xc4)

Rest is clearly OK to parser, but even hyphen in c2-c4 would make it wrong .