I strongly oppose this request because it would only clutter the language without any benefits; actually, it would be a step backwards in terms of reliability and correctness. However, it also seems to me that you suffer from a serious lack of understanding of Rust's syntax, semantics, and overall goals/roadmap. So let me address that first and break down what's wrong with your arguments:
var keyword as an alias for let mut
let mut is not one keyword/syntactic construct, but two. It's a let binding with a mut pattern. In other words, it's a composition of two syntactic elements. You can do let Foo { field_1, mut field2 } = some_struct; in a struct, for example, or if let Some(value) = an_optional { … }. Thus, it doesn't make sense to talk about "an alias of let mut", because you can't alias it, it's simply not a thing. In other words, var wouldn't compose, it would be a very niche addition for one particular constellation of let and mut, which would work in only one case: when the let and mut tokens happen to follow each other. This would be a serious violation of the decomposability of Rust's concrete syntax into a tree, because it is no longer about syntactic structure, but approximately plaintext search-and-replace.
I think people who would like to create mutable variables by default without much cognitive thinking deserve that option too.
People who would like to create mutable variables by default are wrong. The last 30 years of the history of computer science and software engineering proved that immutability is one of the best and easiest ways to achieve reliability, and that for this reason, immutable-by-default is the right choice when designing a programming language. I'm not a purist or an extremist: I don't like pure functional languages that don't allow mutable variables at all. Sometimes, they are necessary and a better solution than trying to enforce immutability in 100% of the time. However, they shouldn't be the default, simply because programs written in a mostly immutable/mostly functional style are much easier to understand and read/write correctly.
Furthermore, I simply can't believe that having to type let mut is so much of a cognitive overhead compared to var that a non-composable, special-cased, new keyword would be worth introducing to the language.
I have a feeling that you haven't been using Rust for a long time. Some Rust newcomers ask for features of languages they have been using, because they don't like Rust's explicitness at first. For example, some people complain that optionals have to be written using an explicit Some(…), but when they gain a bit of experience with Rust, they understand why it is a better way to write optionals. I think you might be in a similar situation with respect to mutability.
It would make rust more natural as a programming language similar to most languages.
Again, it's such a minor similarity or difference that it's not worth the burden of a change to the core language. let mut is not anything weird or hard to understand in particular. Of course, Rust tries to not be super weird or unfamiliar, which is a good thing. However, if the primary goal of a language was to be as similar to other languages as possible, that language might as well just not exist at all, and programmers could use one of the other language it was supposed to be similar to. Rust is not a language that has similarity to JavaScript, C#, Go, or Swift among its primary goals. (Especially in the light of two of those languages being younger than Rust.)
Making every Rust variable declaration immutable by default would greatly affect its adoption rate, it greatly reduces productivity.
No, it doesn't. Rust users are among the most productive programmers in the world, and people love it the most, as it is.
You might say that having let and var would make it confusing; however, Rust already has a similar situation with the const and let keywords, where both function as an immutable variable.
No, they don't. Neither of these two constructs are doing what you think they are doing. const is a compile-time constant, meaning that its value is known to the compiler. const is not used for immutable variables. let is also not used for immutable variables only. let is used for binding names to values, where the presence or absence of mut before a certain name in a pattern shows if that particular name will be a mutable binding.
Alright, so now that I hopefully cleared up some confusion, let's address the last bad part of var: it would be another way of writing exactly the same thing for one particular construct. Having two pieces of syntax for exactly the same semantics is very confusing. It doesn't only lack a significant advantage, it's actually actively harmful. because our monkey brains work like that. If two things look different, we expect that they be different. Similarly, if two things look the same, we expect them to behave similarly. Breaking this intuition is a very dangerous game, because it will lead to confusion, which in turn leads to bugs. It's better to spare ourselves that pain.
).