Well, these may not be in core, but for one thing database operations have always been tricky, and (to my knowledge) no "flag" at the top of one's code ever solved that, e.g. with DBI or DBD::mysql. Despite the fact that input/output from a database might be thought by the coder to be part of the overall I/O for the purposes of encoding, it isn't treated as such, and must be dealt with separately. The handoff between Perl and the DB had to ensure that both were on the same page with the encoding, and for the programmer, keeping track of whether or not a particular item had been encoded or decoded was always a burden, as it was quite possible to overdo either one--Perl would happily allow this (to dastardly results). Then there's other external modules such as CGI, etc. CGI was in core, but it was never UTF8 by default. It also had to be given special instructions to enable and/or convert to utf8 for such things as HTML form input/output. There seem to be many hidden gotchas with coding for unicode, which is why the coder must be alert and prepared for these all throughout the process. "Wide characters" tend to show up when least expected, and can really make a confusing mess of things.