[legerdemain]

This is either wrong or incomplete. When you call a function `f()` with some `&mut`, the callee gets a `&mut`, not a borrowed `&mut &mut`. The callee doesn't borrow the ref mut, it gets the actual ref mut, and for some time you have multiple mutable references in the same scope. How?

[Filligree]

Because the calling function isn't using it at the time. Rust isn't proving something about the number of references in memory; it's proving something about the dynamic behaviour of the program, i.e. that there can be at most one reference actively being used to mutate it, at a time.

Hence there's no problem cloning a mutable reference implicitly, when calling a function. Notice that you can't for instance send it to another thread, however.

[zaphar]

There are not multiple mutable references in the same scope. The mutable reference is only valid for the scope of the function `f()`. This doesn't sound like a problem understanding mutable references but a problem understanding scope.

[scotty79]

It gets `&mut *&mut` (where * doesn't mean a pointer, just deref)

Not sure if that's good that this feature is automatic. Maybe it wouldn't be too bad to call functions like that for consistency:

    go_break_stuff(&mut *my_stuff_ref);

if you want to keep using the reference after the call.

[nicoburns]

The function isn’t borrowing the reference. It’s using the reference to borrow the value thats being pointed to by the reference.

[legerdemain]

I was looking for the word "reborrowing," which I think is crucial for beginners trying to form an effective mental model of Rust semantics.