I disagree. The answer is not just "var" because you have now completely dismissed local variable immutability (something C# does not have). Did you read the link you are responding to? I am also not sure why you believe they want to be different "out of some misplaced spite"...any source for these claims? Finally, Java needs to be easy to parse and backwards compatible, and after all it does have many runtimes by other companies. What if I had a class named "var" (which does happen in auto-generated code)? These things need to be discussed out in the open (something C# did not do during those older decisions). As for the other features you mention, there are many reasons why they are different and many people can argue in favor of Java's approach (e.g. generic type erasure is backwards compatible as opposed reification, async/await are library problems not language ones, etc). They are different languages, they take different approaches to changes, and I believe it is unfair to hand-wavingly dismiss it as "wasting time".
> The answer is not just "var" because you have now completely dismissed local variable immutability (something C# does not have)
It is something that C# does have. It just doesn't allow immutable variables to be implicitly typed, i.e. you can't write something like "const var x = 0;" This lack of let or val in C# is a reminder that "var" was introduced in the language not just to reduce visual clutter, but to support anonymous types, which were in turn introduced to greatly enhance LINQ experience allowing for such nifty feature as "let" clauses in query expressions...
Any of the potential keywords `let`, `val`, `var` could potentially conflict with auto generated code. This would be a breaking change with those generators.