Didn't really consider it in this instance. Was more focused on getting it to work first, then I worry about optimizing later, if needed.

I don't really have a good answer other than to fail if -Mutf8 is set in the ENV since the harness doesn't handle it. It seems to think it is immune from utf8 being settable outside of it's documented calls and ignored "use utf8;" in the code.

Looking at the code itself, the strings were being treated as latin1. If I followed it's instructions on using utf8 I ended up with the faulty latin1 bytes being re-encoded as utf8 -- a double encoding. It didn't seem to be able to deal with the case where it was already encoded. I can't report it as a bug unless I'm willing to come up with a trivial test case for it.

I've reported problems with having unexpected settings in PERL5OPT before (Perl won't make properly, for example) and was told it wasn't their problem -- just don't set things in your ENV. C'est la vie.