This really depends on where the arguments come from. If the encoding
of the arguments is regarded as fixed (to UTF-8) by xsltproc and the
user types the arguments, then this will work under UTF-8 locales,
but not under ISO-8859-1 locales, for instance. So, the process is
non-predictable in this case too. That's why I suggested an option.
If the call to xsltproc appears in a shell script and the user wants
predictability, then the script should switch to fixed locales at the
beginning, in general C or POSIX locales. As 8-bit characters aren't
defined in such locales, accepting UTF-8 encoded strings could be OK
in these locales (there would be no clash with what the user types).