No idea what that means.
"By default, there is a fundamental asymmetry in Perl's Unicode model: implicit upgrading from byte strings to Unicode strings assumes that they were encoded in ISO 8859-1 (Latin-1)"
It's completely false — nothing in Perl accepts or produces latin-1 — and it has nothing to do with anything discussed so far.
LOL. It looks like Latin-1 and quacks like Latin-1, but it's not Latin-1. Yeah, it's just 'byte-packed subset of Unicode'.
"Whenever your encoded, binary string is used together with a text string, Perl will assume that your binary string was encoded with ISO-8859-1, also known as latin-1. If it wasn't latin-1, then your data is unpleasantly converted. For example, if it was UTF-8, the individual bytes of multibyte characters are seen as separate characters, and then again converted to UTF-8."
How about you 'fix' Perl's documentation, and then start arguing... It even talks about 'Unicode' and 'binary' strings (gasp).
This is all the information Perl currently has. Is that an error?
my $x = chr(0x2660);
my $y = chr(0xC3).chr(0xA9);
$x . $y;
Is that an error that perl -wE 'my $x = chr(0x00A9); say $x
does one thing, and perl -wE 'my $y = chr(0x2660); say $y'
does something else? I dunno. You tell me. intuitively, there should be no difference whatsoever, chr
should be consistent, say
should be consistent, everything should be... (confused) (not really).
This is all the information Perl currently has. Is that an error? You can't tell. Perl can't tell. Strings coming from a file handle with a decoding layer should be flagged "I'm decoded text!". Those coming from a file handle without a decoding layer should be flagged "I'm bytes!". Concatenating the two should be an error. These flags do not currently exist.
So you're not even disagreeing. You just hate the word 'Latin-1'. I'm done with you. Have a nice day.