I don't think anyone has seriously tried to teach schoolkids to code in Rust just yet. But the way you'd do it would be to treat it as something close to a pure functional language. .clone() all the things and use Cell<> for the hopefully rare case where you really need shared mutability somewhere. (Even RefCell<> is arguably a step-up in complexity over Cell<>.)
The borrow checking rules of Rust are anything but "weird". They boil down to not mixing up shared references and exclusive borrows; and, more subtly, preserving the distinction between temporary borrows and complete ownership. (I.e. only the owner can dispose an object; when borrowing, you can only give it back.) That's quite teachable, albeit using these rules in practice is not nearly as easy.
But pedagogically, it is difficult to motivate why we can’t read a reference and mutate it in the same scope, since Python, JavaScript, Ruby, Lua, Lisp, Java, OCaml, C, etc. all allow it. It is much easier to accept this hurdle after having seen and debugged memory bugs and data races in, e.g., C.
I’m sure it could be, and maybe I am wrong but I know people say rust has a rough learning curve.
I learned C and Typescript before ever touching rust, and I feel like I experienced no rough introduction. Maybe it’s anecdotal, but I always assumed I learned memory and semi-functional programming first, which made rust a breeze.
> Teaching rust first would just be a weird memorization of rules that you might not appreciate.
That's pretty much exactly the situation with first-time programmers who are taught Java—none of the background to know why it makes the decisions it does.