IDK if it came with unicode 7.0, but there is clarification:

# Note that currently the only instances of multiple aliases of the same
# type for a single code point are either of type "control" or "abbreviation".
# An alias of type "abbreviation" can, in principle, be added for any code
# point, although currently aliases of type "correction" do not have
# any additional aliases of type "abbreviation". Such relationships
# are not enforced by stability policies.

it says “currently”, so it isn’t guaranteed to stay that way, and other types could also be specified multiple times in the future.

so as much as i’d like it if we could follow Alexander’s proposal, i think we shouldn’t extend the function that way if it would either return a name string, a default value, a list of aliases, or raise an exception: too complex.

i think we should create:

unicodedata.aliases(chr, type=(None|'correction'|'control'|'alternate'|'figment'|'abbreviation'))

and make

aliases(chr) return a dict with all aliases for the character, and make
aliases(chr, type) return a list of aliases for that type (possibly empty)

examples:

aliases('\b') == {'control': ['BACKSPACE'], 'abbreviation': ['BS']}
aliases('\b', 'control') == ['BACKSPACE']
aliases('b') == {}
aliases('b', 'control') == []

---

alternative: when specifying a type, it’ll raise an error if no alias of this type exists. but because of the sparse nature of aliases i’m against that.