With MutableSpan, we're introducing a new reference-semantics struct to the standard library that represents a mutable variant of another immutable type. Unlike Unsafe(Raw)Pointer and UnsafeMutable(Raw)Pointer, however, there's (as written) no implicit conversion from MutableSpan to Span. Having to use .span instead is a fairly minor ergonomics issue, but since this is expected to be a currency type I think it's worth at least noting.
If the language supported it, I'd imagine MutableSpan would be a subtype of Span, with a declaration of something like:
@frozen
public struct MutableSpan<Element: ~Copyable & ~Escapable>: Span<Element>, ~Copyable, ~Escapable {
I've talked before on the forums about why I think subtype relationships between structs would be useful and natural, and this is another example of that. While that's not an entirely trivial feature to design, I'd hope that we wouldn't be blocked out of eventually supporting a true subtyping relationship for MutableSpan and Span (e.g. it'd be logical, albeit not essential, for mutableSpan as? Span<Type> to work) because of ABI concerns.
Aside: another example of a mutable-immutable struct subtype relationship
The reason I'm picking up on this particular point is because I've been toying with compiling Swift to SPIR-V shaders (based on the Embedded/no-allocation efforts, with a very basic example working), and realised there's the same Buffer<T>/MutableBuffer<T> (or StructuredBuffer/RWStructuredBuffer in HLSL naming) pattern there that would also benefit from subtyping. I don't think mutability is the only axis on which this is useful, though.