Since the initial question has been answered, I think I could speak a bit about the language as a whole. To start, I am going to call it G, since there is no systems programming language called like that, as far as I can tell. There are however other languages called G, but they are mostly domain specific and not well-known.
If you intend this to ever take off then please
give it a name that would be easier to search for =P
My general intention is to make programmer errors harder. I am aware this may annoy programmers when trying to get used to it, but I am also aware it will reduce debugging time, since errors will be more rare. Consider a divide-by-zero error. If the compiler can't ensure the divisor is non-zero, it will error right at compilation time. Consider now an out-of-bounds error, which involves using a variable as an index to access an element of a 12-element array. If the variable has the value 12 or greater, or is negative, it will definitely result in an error which, unlike the divide-by-zero error, may not even be evident at runtime. The compiler should be able to ensure the variable is in range in order to compile the code.
Random comment: try to make it as painless as possible. A lot of language designers see programmers not adding error checks and think the problem is that they're not forced to do it, rather than wondering if it's an usability issue and what can be done to reduce the need for error checks as much as possible (and where needed, help make it be likely to handle it in a reasonable way instead of doing something dumb like aborting because they're rushing to meet a deadline). Especially since having checks everywhere can add clutter.
This is not
an easy problem to solve, mind you (and I'm sure there are many
opinions on how to achieve this). Just asking you to first figure out where you can help simplify it while still retaining a reasonable outcome. Maybe you can find something many people didn't think on =P
A common case for undefined behaviour is uninitialised variables, and this is something I would rather forbid right from its roots (except for accessing values through pointers, where the compiler can't do anything at compile time). Another option would be to implicitly initialise to zero.
Yeah, I'd say each type should just have a "default" value (e.g. 0 or false) that becomes the initialized value when a programmer doesn't specify one (and if later it turns out it isn't used, the compiler can easily just optimize it out). I think a lot of beginners expect variables to be a value like that by default, enforcing it in the language would help make it reliable.
Booleans should not be built on top of integers like in C. Consider the "a + (b == c)" expression. Is there any real use for it?
If you have an array with two elements representing an on/off state, you can use a boolean as an index to the relevant value immediately (I've done this in some cases, yeah, mostly when dealing with rendering interfaces).
Honestly though lack of that feature would be a minor problem, so just get rid of it. If you're worried, you can just add a way to explicitly cast a boolean into an integer (yielding 0 or 1), since the cast is explicit the code would already make the intention clear. This could possibly help in some other situations too.
While we're on casting: do not
allow implicit casting between signed and unsigned. This is already a significant source of surprises in C. If somebody needs to mix together signed and unsigned integers, just require it be done with an explicit cast instead (which also lets the programmer decide which of the two types is best to use).
And one would think that Google's got the best programmers. Apparently, not.
After fighting non-stop with some stupid Android limitations in a tablet, I can confirm.