I don't think the XBetza definition is ambiguous. It says "all moves of the most-recently moved piece type". 'All' really means 'all', so including double-pushes and e.p. captures. (I do not consider promotion part of the move.) It also mentions that it imitates the piece type, rather than a particular piece. So it doesn't matter whether the piece that moved still was able to make its initial move; it is the Imitator that should satisfy the conditions for making the initial move.
This is also how I implemented it in the Diagram: the I atom in the move decription of the Imitator's move is simply replaced by the move description of the piece it imitates, as if the Imitator was of that piece type.
Problems could occur with piece types that do not have a fixed move, like the Elk in Elk Chess. Because the Diagram treats that as two piece types, that promote to each other depending on where they land. The implementation would then imitate the type the Elk promoted to, even if it was on a square shade where a 'unified Elk' would have moved differently. I see this more as a problem / ambiguity in the implementation / definition of the Elk than in that of the Imitator.
I don't think the XBetza definition is ambiguous. It says "all moves of the most-recently moved piece type". 'All' really means 'all', so including double-pushes and e.p. captures. (I do not consider promotion part of the move.) It also mentions that it imitates the piece type, rather than a particular piece. So it doesn't matter whether the piece that moved still was able to make its initial move; it is the Imitator that should satisfy the conditions for making the initial move.
This is also how I implemented it in the Diagram: the I atom in the move decription of the Imitator's move is simply replaced by the move description of the piece it imitates, as if the Imitator was of that piece type.
Problems could occur with piece types that do not have a fixed move, like the Elk in Elk Chess. Because the Diagram treats that as two piece types, that promote to each other depending on where they land. The implementation would then imitate the type the Elk promoted to, even if it was on a square shade where a 'unified Elk' would have moved differently. I see this more as a problem / ambiguity in the implementation / definition of the Elk than in that of the Imitator.