You need to understand that BlobURIs do not represent any data. They are just links, pointing to some resource in memory, just like the string https://stackoverflow.com/questions/54613972 doesn't contain any of what you are reading per se, it just points to a server instruction which will then generate the page.
Their link can be said to be immutable, once you generated it using URL.createObjectURL(target), you can not change its target, just like if you used the const keyword.
Take for instance const foo = {} now foo can't be set to something else than this object. But the object that is pointed by foo address is still mutable. foo.bar = 'baz' can still be done.
const foo = {};
try{
foo = 'fails';
}
catch(e) {
console.error(e);
}
foo.mutable = true;
console.log(foo);
Well for blobURIs it's just the same. The blobURI points to a target object, this link can't be changed, but the target is still mutable. This is true for MediaSource objects but also others.
If you remember a few years ago, we were still able to use blobURIs for MediaStreams (was a bad idea), it was the same process, the blobURI was pointing to the MediaStream object, in an un-mutable manner, but the media-data was in constant mutation (a stream).
And even for Files, you can very well have a blobURI that points to a File on your hard-drive, this won't block you from removing it from your HDD, even though the blobURI now points to nowhere anymore.
The one particular case with this regard is the case of a Blob, generated from data in memory (i.e not just a pointer to a file on disk). Here the data held by the Blob is immutable, so in this case, the blobURI indeed points to an object that does hold immutable data.
And for you request to have a blobURI pointing to some data stored in memory, but still be able to modify this data, this can't be done...
That is because this scenario implies that you created your blobURI from a Blob object using data in memory, which once again does hold data in an immutable state.
