The posted code shows that printing to STDOUT in a cmdline script gives the same result for both strings (because non-mod-perl2 STDOUT has an associated encoding (latin1 by default, changeable to utf8) - either will work if it matches your terminal).

Printing to STDOUT (or using r->print) under apache does not have this property - you get different behaviour for the two approaches.

i.e. the problem as I see it is that STDOUT under mod_perl2 lacks the utf8-awareness built through the rest of the perl I/O layer, with no way of enabling it.

Yes, you can manually encode, but that can necessitate additional copying (you can pass $r as an output destination to TT, which will do the wrong thing if you're working with unicode strings, since it won't call encode. Yes, you can build to a scalar, encode that and print that but it's a shame the extra copy is needed when perl has a mechanism for this which isn't being used.