The fact that passing such value to a function needs to take into account mutability of its fields means these literals create new types. You're not proposing any syntax or trait for these types, so it will not be possible to use them in structs, function arguments, or return types. Is that intentional?
This type-based mutability is also a novel concept for Rust, and doesn't match what mut is currently doing. Currently mut is about bindings, not values. It's attached to names of variables, not the data behind them. Owned data is always mutable. In fact, in Rust immutable data doesn't exist. Any apparent immutability is only a temporary side-effect of how the data is accessed.
This is legal and essentially a no-op in Rust today:
let mut a = a;
but if immutability was a property of the type, then it would have to become some kind of type coercion.
This is also valid, because Rust doesn't have immutable data:
let a = A { x: 0, y: 1 }; // pretends to be immutable
{a}.x = 1; // can mutate, because moves break connection to "immutable" `a`
Personally, I'd rather remove current mut (not &mut) entirely from the language, because it's not part of the type system, it creates a false impression of immutability where none exists.