Yes, that's fine as a take home message.  Though it should be pointed out that the sequence of layers does work only in that exact order. I.e. simply adding the :crlf layer last is not sufficient, you also have to remove it left of the UTF-16 layer, which is what the :raw does.  In other words, saying ">:encoding(UTF-16LE):crlf" is not enough — not even with the new patch!  What adds to the unexpectedness is that some people might not even be aware that (on Windows, by default) there is another :crlf layer left of the UTF-16 layer when saying ">:encoding(UTF-16LE):crlf".

Anyhow, I was mostly commenting on p5140-Selected Bug Fixes — in particular on this statement

When binmode FH, ":crlf" pushes the :crlf layer on top of the stack, it no longer enables crlf layers lower in the stack, to avoid unexpected results [perl #38456].

which sounds as if it was meant to fix the issue...

So the comment http://perl5.git.perl.org/perl.git/commit/7826b36fbbf24cfa659558ee5af3de424faa2d5a doesn't match the codechange? Meaning this #38456: The :crlf PerlIO layer doesn't like the :encoding layer. is still a bug (though producing a slightly different effect) ?

Or should :encoding() rearrange order of crlf to fix it?

Or?

http://perl5.git.perl.org/perl.git/blob/HEAD:/t/io/layers.t doesn't actually test any UTF-16 stuff