bos:
It is perfectly true that you can take an existing ByteString and smoosh its innards however you like, because the authors sensibly made this possible. However, doing so breaks referential transparency, so it's not encouraged as a general principle. The fact that a ByteString has a pointer to a nice flat piece of memory inside is an implementation detail, and doesn't change the fact that it's intended to be immutable.
If you personally know for sure that you're not going to accidentally screw yourself by running a lazy computation on a ByteString that you then modify while the computation is still thunked, then by all means, go to town. But any claim that this is generally a safe thing to do would be completely wrong. It's very much in the realm of "here's the gun, there's your foot, be careful".
Perhaps Peter just wishes to define a newtype MutableByteString type for mutable use, with much the same representation as the existing immutable ByteString, but without the purity guarantees and with all operations in IO? -- Don