
Quoth Brandon Allbery
, ... Seems obvious to me: on the one hand, there should be a plain-ASCII version of any Unicode symbol; on the other, the ASCII version has shortcomings the Unicode one doesn't (namely the existing conflict between use as composition and use as module and now record qualifier). So, the Unicode one requires support but avoids weird parse issues. OK. To me, the first hand is all you need - if there should be a plain-ASCII version of any Unicode symbol anyway, then you can avoid some trouble by just recognizing that you don't need Unicode symbols (let alone with different parsing rules.)
What? The weird parsing rules are part of the ASCII one; it's what the Unicode is trying to *avoid*. We're just about out of ASCII, weird parsing is going to be required at some point.
What what? Are you not proposing to allow both ways to write composition, "." and "<unicode symbol>" at the same time, but with different syntactical requirements? Unicode characters as code would be bad enough, but mixing them with a hodge-podge of ASCII aliases with different parsing rules isn't going to win any prizes for elegance. Donn