I'm guessing this request was inspired by something similar to Ruby's method_missing method. method_missing is often used to implement behavior that involves the name of the message being passed to an object (the official example is a class that converts between Roman and Arabic numerals and uses method_missing to redirect messages such as "roman.III" to "roman.roman_to_arabic('III')"). Another usage is undefining all methods and then intercepting the calls, such as in RubyQuiz #95, where that approach was used to convert code blocks to S-expressions.
The former use isn't really that useful without an object system to restrict the scope of a single method_missing definition. And, of course, any object system could implement its own method_missing. And the second usage, in addition to being pathologically uncommon, could be implemented in Arc using macros, or, where function calls must be intercepted at runtime, by iterating through all values in the namespace (or even a closure as well) and overloading functions to add hooks that perform some other behavior if some boolean is set to true. (Of course, said boolean would probably need to be in a table keyed by the current thread.) Of course, that would require being able to retrieve a list of all values in a namespace or closure to iterate through (hmmm...now there's an idea).
I think the Py3K solution sounds right: Two different types of strings, 8-bit byte-strings and full unicode strings, with encode and decode functions to convert between the two.
Without this strict separation you get the wart that is Pythons current string-support.
Or just one type of string: unicode character strings (which is sequences of unicode code points). Then a seperate type for byte arrays. Byte arrays are not character strings, but can easily be translated into a string (and back).
...and this seem to be exactly what MzScheme provides :-)
Strings in MzScheme are sequences of unicode code points. "bytes" is a seperate type which is a sequence of bytes. There are functions to translate between the two, given an encoding.
Python 3000 is close to this, but I think Python muddles the issue by providing character-releated operations like "capitalize" and so on on byte arrays. This is bound to lead to confusion. (The reason seem to be that the byte array is really the old 8-bit string type renamed. Will it never go away?) MzScheme does not have that issue.
