That looks more reasonable, though I don't see why the i386 CI is failing, I couldn't reproduce it with a -m32 build on Debian.

I have started a smoke-me to see what other platforms may have problems.

I suspect it is something in strcollxfrm. Is there a way to turn on -DLv for that platform?

Is there a way to turn on -DLv for that platform?

You could add that to switches for the fresh_perl() call, possibly repeating the call with that switch if it fails without the switch.

I looked over the code again, and realized that it copied as-is the initial portion of the string before the first bytes that needed to be translated, but did not advance the destination pointer to account for that, so that the translation overwrote the as-is portion. In the other string, no translation was needed, so the string's initial segment was intact, and was getting compared with the 10FFFF. Platforms could differ in how they lexically compare those

Platforms could differ in how they lexically compare those

Ideally we'd test the intermediate transformation from perl string to no-NULs-no-extended-UTF-8 form, since that doesn't depend on the underlying locale implementation.

To do that we'd need to split that out into a separate function and export it, but that's not something we've generally done in core perl.

It could change behaviour, I think it could use a brief perldelta entry.