The short answer to Karl's question is that there will not be an
absolute guarantee.
The long answer is that, partly for the reasons he's mentioned, this
won't be a practical problem.
A. Most of the living scripts that are in wide use have been encoded,
including whatever digits are in use.
B. People reviewing encoding proposals include programmers who would
object to scattering digits
Thus, the only time this would be an issue is if there were some
exceptional circumstances. And, as the name says, those circumstances
could force an exception. If that happens there are two possible
consequences:
1. The script in question is important enough that everybody will build
in exceptions into their conversion algorithms
2. The script is so unimportant, that its number system won't be
supported (i.e. it's treated just like other text).
So, for extending your computer language, there's no reason to hold up
support for many important scripts, just because of a hypothetical
future exception.
A./
PS: just because I suspect more than one existing implementation to be
offset-based, there would be tremendous pressure to prevent exceptions
already :)
PPS: a very hypothetical tough case would be a script where letters
serve both as letters and as decimal place-value digits, and with modern
living practice. Having a policy like you suggest would officially make
that unsupportable, but there are other cases, like the language that
wanted to used @ sign as a letter, that are de-facto unsupportable with
the modern infrastructure. My suspicion is that users of such a script
would realize that their method is de-facto unsupported/able and find
some way to change their ways. Changing practices in the face of
changing technology is something that happens all the time, not only to
small communities - but that's an entirely new subject :)
