REXX 6.0 Unicode build vs. legacy 8-bit semantics: migrating a low-traffic text script

REXX 6.0 introduced optional Unicode (UTF-8) support, allowing scripts to read, write, and manipulate international text natively. For a low-traffic workload that currently handles international data through external conversion tooling, moving to the UTF-8 build could remove that dependency and simplify deployment and maintenance.

The transition crosses a compatibility boundary. Binaries compiled without UTF-8 default to legacy code page 1252, and scripts that depend on single-byte string lengths or implicit code page conversion may fail or produce mis-encoded output under the Unicode build. Unicode support is also not enabled in every distribution, so the target build's capabilities need confirmation before any code changes.

The unresolved decision is how much of the existing 8-bit string logic must be reworked, and whether one script can remain portable across both build types.

1. Which string operations, such as length, substring, and position handling, need revision before a legacy script runs correctly on the REXX 6.0 UTF-8 build?
2. Can a single script detect at runtime whether the interpreter is Unicode-enabled, so it can avoid code page 1252 assumptions?
3. What migration approach keeps output consistent for a low-traffic workload without reintroducing external conversion libraries?