The main integration points between compilers and GCs are pointer maps and write/read barriers. I don't see a good way to do a GC-as-a-library given the need for the GC to contribute barrier code, which has to be tightly optimised. That's one reason Java/.NET use JIT compilers: there's not yet any one-size-fits-all GC algorithm, and all the best ones need tight compiler integration, so allowing you to pick your GC on the command line and then that impacts how the code is compiled represents a way to square the circle.
Pointer maps (stack maps) are basically what rust will get in its gc support. Rust has a stricter view on mutability, so GCs would be immutable-by-default like Rc is -- mutation would be very explicit and thus barriers are easy to insert. Yes, some optimization opportunities are lost ... but I'm optimistic :)
Ultimately it will never be as good as what Go (or whatever) can do, but it might just be good enough for the application. For cases where you are interoperating with an existing GC or using gcs for a persistent datastructure or something, the GC isn't pervasive so perf doesn't factor in as much as in, say, Java, where everything lives on the heap and the GC has to optimize a lot of extraneous stuff. Non-pervasive usage of GCs mean that the programmer is using the GC only where needed, so consequently less optimization is needed :)
What the post proposes will require a pervasive gc, however. But that GC will be pervasive in the language living on top of rust -- and that compiler/transpiler can attempt to perform optimizations. Can't exactly JIT to rust, though, so it might end up slower. Not sure by how much.
