Yes, I think it's unfortunate that this implementation detail leaks to the perl programmer, but I think it's normal that errors from the programmer lead to program errors. The encoding that the original blog poster meant to use is UTF-8. Period.

I made the same error (in HTTP headers), and I'm not blaming the HTTP RFCs for not introducing an alias. (And no, the browser did not complain as noisily as perl did).

I'd actually rather have Encode not ignore case and also 'die', especially in the case of /^utf/i. DWIM to avoid being too brittle can be nice. DWIM to the point of being mashed potatoes makes it hard to build reliable software. Having "utf-8" silently become "UTF-8" when it looks a lot more like "utf8" is "a DWIM too far", and even more so for "UTF8".

Browsers should not be in the business of complaining about little mistakes in pages I visit. I don't write the vast majority of pages I visit so complaining to me about their quality mostly just a good way to annoy me.

So if you are using a browser and expecting it to tell you about little mistakes that you made, then you are a fool. Sure, test in a browser. But also test with something that actually has motivation to tell you about little ambiguities (like a validator).

Perl and Perl modules should certainly be in the business of being able to complain about little mistakes. It isn't like you can send your code to the ISO validator and have it check that you spelled the arguments to Encode::decode() correctly. Encode::decode() should provide that error checking itself.

Update: Actually, I hope that there are at least plug-ins for some browsers that offer optional validation / complaining about little mistakes.

- tye