At the time, I wasn't sure what to make of this. However, while trying to figure out where this flag gets set, I noticed something. perliol seems to be very clear:

"unix"

A basic non-buffered layer which calls Unix/POSIX read(), write(), lseek(), close(). No buffering. Even on platforms that distinguish between O_TEXT and O_BINARYthis layer is always O_BINARY. (emphasis mine)

This statement seems to imply that PERLIO_F_CRLF should never be set on a 'unix' layer. Not even on Windows.

Note that if I open a simple file, and check that filehandle, the CRLF flag is not set on the bottom-most 'unix' layer:

So, PERLIO_STDTEXT is "t" on Windows, and this leads to l->flags |= PERLIO_F_CRLF;, but that doesn't explain why the bottom-most 'unix' layer on STDOUT in cmd.exe has this flag set whereas the same type of layer on a plain filehandle does not.

Given the guarantee expressed in the documentation, maybe there should also be a:

PerlIOBase(f)->flags &= ~PERLIO_F_CRLF;

Hmmmmm …

Another update

I guess that was a red herring. I built a perl with that line. The flags value is "fixed", but the output problem remains.

I am in the process of migrating my blog content from Google's
Blogger platform. Things are going to be in a state of flux during
this process. Comments and feeds, in particular, are disabled for the
time being. Thank you for your patience.