Not quite the same. If you had ‘destructuring’ *, the meaning of mut would have to be different, since * would be a structural element rather than a binding modifier. Right now, if you wanted a mutable-binding-of-reference-to-the-slot, you would write mut ref x, which makes the binding ref x mutable. However, if you wrote mut *x, the mut would no longer be applying to the binding, it would apply to the slot corresponding to *x, making mut *x equivalent to ref mut x. To get a mutable binding, mut would have to be applied directly to the binding, like *mut x. With a ref binding modifier, the meaning of incantations involving both ref and mut are essentially arbitrary, and I guess it made sense not to force people to read them inside out the way you do with structural pattern elements. After all, you’re constructing a binding rather than deconstructing a value at that stage.
Just because I didn’t quite take your meaning immediately, the type level operation corresponding to Some(_) is Option<_>. At first I thought you meant that the type-level operation has to have the same syntax as the value operation, which of course doesn’t work in general. That it happens to line up for & is the exception rather than the rule, which is what threw me off when I first read your comment.
Of course, you could create a type-level operation:
type Dereffed<T> = <T as Deref>::Target;
But yeah, if we limit ourselves to canonical types rather than arbitrary aliases, then it’s very clear that & adds structure while * removes it. If you think of patterns as destructuring, then reversing * is undestructuring. Thus, it doesn’t fit with everything else (though it does have a clear meaning in the more general logic of matching: matching *x to y makes x = &y).
