The ability to support GC'able DOM references in browsers through integration with the host-side GC is absolutely being worked on, it just took several years to stabilize because it's a tricky feature. It will also allow GC'd languages to target standalone runtimes more easily. The developers just didn't want to block the early 1.0 spec, early toolchain and software support, etc. all on that. It was just easier to ship the C/C++ style memory management model because a lot of existing code could immediately be reused and it was easier to implement. But it was always planned from a very early phase to have GC integration, at minimum, since web usage was always a big priority.
The string story is a bit unfortunate (how to handle conversions between modules in different languages). Until the component model is fully fleshed out I don't think there's a clear answer here besides things like bindgen-style interfaces, but I agree it's a sore spot.
I don't know what a rewrite of the spec would achieve at this point since most of these things would be impossible to get right on the first try, I suspect, and the current one is actually pretty good for the cases it does support.
If you do a rewrite you can throw away the memory buffer and handle all data with opaque pointers, thus allowing complete integration with the GC.
And yes, you could just leave the buffer dangling there, and tell people not to use it, but it doesn't ease any part of the task of designing the new thing.
The string story is a bit unfortunate (how to handle conversions between modules in different languages). Until the component model is fully fleshed out I don't think there's a clear answer here besides things like bindgen-style interfaces, but I agree it's a sore spot.
I don't know what a rewrite of the spec would achieve at this point since most of these things would be impossible to get right on the first try, I suspect, and the current one is actually pretty good for the cases it does support.