WASM takes care of all the GC bits, but in turn you have to use its ref, struct, and array types for everything. Making vtables is straight forward. Fat pointers for interfaces require an object though, since you can't do your own pointer layout.
In web contexts GC should be great because browser GCs can work across DOM, JS, and WASM, so you can hold a reference to a node that you get via JS, and if you remove the node from the DOM and discard the reference, it'll be collected just like in JS.
The big downside is data transfer over the Wasm boundary requires a lot more copying with GC. Byte arrays like (array i8) are completely opaque to the outside, so you need to vend individual byte access functions to read data. On the WASI side, it only lowers to linear memory, so you need to allocate some from scratch space, then copy into GC structs and arrays. Strings are doubly awful because of this because you also have to deal with encoding.
GC also doesn't support multi-threading yet.
Some of this is supposed to be fixed by things like https://github.com/WebAssembly/design/issues/1569 and WASI lowering to GC types. stringref would have been great, but that appears to be dead for now.
So I'm on board and optimistic these things will get fixed, but GC is still a bit of a second-class citizen for now.