Speaking of improving functionality:

> Having unicodedata readily accessible to the str type would also permit higher a fidelity unicode implementation. For example, implementing language-tailored str.lower() requires having canonical combining class of a character available. This data lives only in unicodedata currently.

Benjamin, can you say more about the behavior you have in mind here? I don't entirely follow. (Is or should there be an issue for it?)