We're likely to at least add an Inout<T> (name TBD) that represents a single mutable reference, analogous to &mut T in Rust the same way that MutableSpan is analogous to &mut [T] (which I would argue has to be understood as a separate type from the scalar &mut in some ways).
This is an interesting idea. I certainly wouldn't call it natural, though — it is completely unlike the normal behavior of consuming.
Mmm. This is tricky, though, because ultimately the caller does want its span back. In Rust, this re-borrowing is all done with a lot of special-casing of the reference types, and, again, I think it amounts to the reference types basically just not behaving like normal affine types except as a conservative approximation.
Personally, I would rather add a new kind of ownership than to have a set of exceptions to the non-copyable type rules that essentially amount to "whatever Inout and MutableSpan need". That seems like a recipe for under-specified behavior. Rust does not seem very clear about exactly what's allowed here, either.
Part of my thinking for this is that I think there's a plausible future direction of supporting "exclusive use" as a fully-general kind of access to storage. For example, you ought to be able to write a coroutine accessor for a property or subscript that gives clients exclusive use of the current value — it's something we can do for physical storage, so a computed storage declaration that's trying to exactly represent physical storage ought to be able to do it as well. I suppose the counter-argument is that we wouldn't need exclusive use at all if we just special-cased spans and references the right way; maybe I need to think about it more.