> Does it (a :crlf layer) still interfere with tell() even when it's disabled ?

No. But if you later add (binmode) a :crlf layer then it can enable it at the wrong 'level'. This is a common mistake when using utf(16|32) eg.

# wrong way to write utf16
open $fout, ">", $file or die;
binmode $fout, ":encoding(utf16le)" or die;
print $fout "abc\n123\n\n";
close $fout;
[download]

this results in CRLF being output as "0D 0A 00" bytes. Oops. What you need is:

# OK
open $fout, ">:raw:encoding(utf16le):crlf", $file or die;
# etc.
[download]

Bascially there are known bugs with mixing :encoding and :crlf layers and suggest that if you need both that you test well to ensure you're not hitting them. (Also check the Perl bug database).

Your code gave for me on windows:

3: unix  4195328 crlf  4195328
4: unix  4195328 crlf  4195328 perlio  4195328
[download]

> If one has to use open($fh, '<:raw:perlio', $file) to get a clean and buffered binary stream this unconditionally forces a :perlio layer onto the stack, which in turn inserts a :unix layer below it.

NB. my original point was about creating a raw byte stream that you *then* wanted to add :encoding layers to.

NB. the reason for the :perlio in  open $fin, "<:raw:perlio" is to give the filehandle the ability to be -B/-T -able. Consider:

C:\>perl -we "open $fin, '<:raw', $^X or die; die if -B $fin
-T and -B not implemented on filehandles at -e line 1.

C:\>perl -we "open $fin, '<:raw:perlio', $^X or die; die if -B $fin
Died at -e line 1.
[download]

If all you want *is* a binary, then either of:

open $fin1, "<", $foo or die;
binmode $fin1;

open $fin2, "<:raw", $bar or die;
[download]

are equivalent (and you can forget all my ramblings :-)