Some quick notes about interesting features of the design:
* Source file encoding is required to be UTF-8. Strings are UTF-8. No apparent provision for binary strings, but I haven't delved into the string API.
* Retains the C/C++ definition of overflow of signed integers cannot overflow, unsigned can. That's o_O-worthy; the two should be aligned, and if they can't overflow, provide some form of wrapping integers as well.
* Yay, tuples.
* Struct type syntax is ... weird? {.name: String, .count: i32}
* Expressions. Partial order for precedence (i.e., a | b * var and let for declaring variables; one is constant, the other not--that's somewhat jarring. It seems that the : is mandatory, and inferred type is : auto instead of letting it be omitted? Feels unnecessarily verbose to me.
* No goto, nor labeled break and continue. Huh. Also, 'for (var name: String in strings)' is again feeling unnecessarily verbose... (Can break break out of an if statement, or does it have to be a loop?)
* You declare "returned var c: Circle" instead of relying on named return value optimization. Again with the verbosity, although I haven't yet reached copy/move constructor stuff to understand how much automagic happens.
* The [me: Self] syntax is weird. I'd like something closer to the C++ deducing this syntax or Rust's &self/&mut self, where the type of the this parameter is specified via the first argument rather than what feels like a somewhat-out-of-bounds information.
* Mixin (aka multiple inheritance) is unspecified at this point.
* The keyword for enums is "choice"? Really?
* Name lookup retains the C/C++ rules of need-to-declare-before-use. Again, is this really necessary? It's fiddly...
* The [me: Self] syntax appears to be a specific instance of the generalized syntax for generics, but only for method parameters, because generic types use () instead. Again, why differentiate from the C-family standard practice of for generics? Also, the : versus :! in generics strikes me as overdrawing the weirdness budget one too many times. Props for using something closer to a constexpr if than C++ SFINAE; SFINAE is not a design model I would carry forward in any future languages.
* Stable ABI appears to purely be defined in C ABI terms. Sigh, can we get people on these language committees together to start thinking about post-C standardized ABIs?
* Async, coroutine, lambda stories are unclear.
* Error handling also unclear. (That's kinda important!)
* Not clear from the main design document is how the distinction--if any--between trivial/nontrivial copy/move types work. There appears to be an explicit move operator (with obvious syntax ~x), so support for nontrivial move or immovable is better than Rust already, but the avoidance of a NRVO setup still makes me wonder what the actual story is here.