What is your evaluation of the proposal?
+1
Is the problem being addressed significant enough to warrant a change to Swift?
Yes
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Swift's unicode support is better than any other language I've used, and this is a great addition. Useful, clear and at an appropriate abstraction level.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Participated in Character discussion (apparently there were 2 separate discussions), read the proposal, checked out some unicode stuff.
On the issue of whether or not the properties should be nested in a .properties structure: I don't mind either way, but we should consider that Character will likely have many equivalent properties, and it would be useful to keep the structure consistent. I think it should be easy to flip your code between the scalar/character levels without adding/removing ".properties" everywhere. For example:
if myString.unicodeScalars.contains(where: { $0.isWhitespace }) { ... }
// Oh, no! We discover that we should be using characters (or vice-versa)...
if myString.characters.contains(where: { $0.isWhitespace }) { ... }
Also, I could not find any realistic usecases for u_charAge in the wild, so I don't mind Unicode.Version just being a tuple. I don't think it's a very "interesting" type (as in, nobody will care about writing extensions or adding protocol conformances to it).