for MutableRawSpan to be any safer than raw pointers, i think it needs to have a safety guarantee that all of its bytes are always initialized across API boundaries like function calls, just like other safe types.
if users of a MutableRawSpan are allowed to store uninitialized bytes, then no function that takes one as an argument can trust that it's safe to use. the same goes for yielding/mutating accessors. [UInt8], Span<UInt8>, or RawSpan can't provide a safe mutableBytes property if users can write uninitialized bytes into their storage (unless they immediately overwrite their entire storage after... which would be hilarious but completely useless).
IIUC, unsafe code could be allowed to write undefined bytes, so long as it guarantees that those bytes are defined at some point before they are ever read. this the same safety guarantee as any other safe type: if you get one through a safe API boundary, it's guaranteed to be completely valid, but if you muck around with unsafe code, it's your responsibility to ensure it's valid by the time you're done with it.
it is impossible for MutableRawSpan.storeBytes(of:as:) to be a safe API if it takes a BitwiseCopyable, as BitwiseCopyable types are allowed to have uninitialized padding bytes[1]. we could provide a safe version if we required the input to conform to a hypothetical FullyInhabited protocol (or BitwiseStorable 
).
well or
storeBytescould be defined to write any padding bytes as 0s, though that would add performance overhead ↩︎