Not only because it's young, also because we _do_ learn from mistakes made in other languages.
For example, I do not see PL/I's choice to make none of its keywords reserved names (IIRC, defended on the argument that one cannot expect anybody to know all the reserved words) repeated much anymore in Algol-like languages.
As another example, IDE/language pairs such as Eclipse/Java have learned us the advantages of languages that are easy to parse and where there is little ambiguity even in incomplete or incorrect programs (it makes syntax coloring easier, and allows for refactoring tools that are somewhat reliable on non conforming source code)
Whether generics get retrofitted will be the measure of this. I suspect they won't, because by the time a Go 2.0 timeframe arrives, the thinking will be something like "Time has shown that we thrived without them, so despite commentator gnashing, they're simply not required."
C preprocessor stuff works with text and text only. That's why it's quite hard to make things elegant. Tools can work with text and anything else you can think of. So they can potentially be better. But I don't know what could be done at this point (in fact, this might be a good problem to be analyzed from a theoretical side).