In the first case you are creating a mutable binding with type &U, in other words you are binding u to a reference to a U. This means that you can modify the referenced value or reassign u to any other reference to U.
In the second case you are trying creating a mutable binding to the u field within a &Y. This binding has type Unot type &U. This means that you can modify the value or reassign u to any other U but you can't assign a &U to u because it is the wrong type.
struct U;
struct Y {
u: U,
}
let Y { mut u }: &Y;
u = U;
u = U;
// Saying directly what you mean
let Y { ref u }: Y;
u = &U;
// The nesting binding can't be mutable initially as far as
// I'm aware, but you can always "reset" the mutability of
// owned variables
let mut u = u;
u = &U;
Or:
// Here, "match ergonomics" make this the same as above
// because the left side is not a reference pattern and the
// right side is a reference... and there's nothing to
// "reset the binding mode"
let Y { u }: &Y;
u = &U;
let mut u = u;
u = &U;
Or (not recommended):
// This is the same "match ergonomics" case as before; the `ref`
// is just ignored. The mix of styles can cause confusion.
let Y { ref u }: &Y;
u = &U;
let mut u = u;
u = &U;
What's going on with your original example then? This:
// `mut` resets the binding mode in a weird way so that
// this is the same as `let Y { mut u }: Y;`. So what
// you get is a mutable binding with type `U`.
let Y {mut u} : &Y;
u = &U; // not work , expected struct `U`, found `&U
(or any equivalent variation) is not what you want, because that creates a &mut U binding, not a mut &U binding. Hence the need for let mut u = u; later on if you want to reassign u.