It has been pointed out that the documentation for the cmd.exe program says

/A Causes the output of internal commands to a pipe or file to be ANSI

even though the output is actually in the OEM code page. Why do errors such as this persist?

Because ANSI sometimes means OEM.

The “A” versions of the console functions accept characters in the OEM code page despite the “A” suffix that would suggest ANSI. What’s more, if you call the SetFileAPIsToOEM function, then “A” functions that accept file names will also interpret the filenames in the OEM code page rather than the ANSI code page.

“There are two types of people in the world: Those who believe that the world can be divided into two types of people, and those who do not.”

There are those who mentally divide the world of characters into two groups: Unicode and 8-bit. And as you can see, many of them were involved in the original design of Win32. There are “W” functions (Unicode) and “A” functions (ANSI). There are no “O” functions (OEM). Instead, the OEM folks got lumped in with the ANSI folks.

There are also those who realize the distinction, but out of laziness or convenience often use “ANSI” as an abbreviation for “an appropriate 8-bit character set, determined from context”. In the context of console programming, the appropriate 8-bit character set is the OEM character set.

The person who wrote the online help for cmd.exe clearly meant ANSI to mean “That thing that isn’t Unicode.”

/A Causes the output of internal commands to a pipe or file to be ANSI
/U Causes the output of internal commands to a pipe or file to be Unicode

I’ll leave you to decide whether this author belongs to the “Everything is either Unicode or ANSI” camp or the “just being casual” camp.

Related: Keep your eye on the code page.