@szepeviktor any insights into what the root of these character encoding issues are?

Strange

<?php echo mb_detect_encoding("日本語");
UTF-8

Got it.
Technically it works fine, "日本語" is really 3 characters long but takes up 6 chars' width!
You can see above it: "It-al-ia" = 6

Please use mb_strwidth()

And $length = preg_match_all( '/.{1}/us', $str ); instead of iconv.

It's actually a problem with safe_strpad(). I've worked out a fix, but it still doesn't work with Hebrew and Burmese:

Burmese has multiple signs in one position, which is unclear to me.
This Hebrew writing has two (separate) accents (actually vowels) under the letters.
I think this is why those strings are calculated two characters more than the actual width - making padding narrower.
PHP i18n seems shallow. Java i18n too.

You can strip out hebrew vowels: http://blog.shaftek.org/2005/06/03/removing-vowels-from-hebrew-unicode-text/ before padding it. More details

What font do you use on your terminal?

You can strip out hebrew vowels

Ugh. Could we do similar detection for Burmese?

What font do you use on your terminal?

Source Code Pro.

Please do not support Burmese language.
I write the code when you find me a Burmese wp-cli user.

I write the code when you find me a Burmese wp-cli user.

It's a deal :) Thanks for your help with this.

And $length = preg_match_all( '/.{1}/us', $str ); instead of iconv.

This is why we're using iconv(). If we used preg_match_all(), we'd have to roll our own error notice. Is there something I'm missing?

if non-ascii encoding is present

In what case should preg_match_all return an error?
/.{1}/us does length measurement only.

preg_match_all returns false on non-UNICODE input.

php -r 'var_export( preg_match_all( "/.{1}/us", "'$(echo -n óra|recode utf8..latin2)'") );'

Ok. I think this is good enough for now. We can revisit later as needed.