Like I said, the GC will look like a normal library and be loaded the normal way. It doesn't hook into the compiler like a plugin (no library code is run at compile time), it just makes use of magic traits and functions which signal meaning to the compiler. Such traits and functions already exist in rust for non-gc purposes and get used all the time.
Rust also has that replace-allocator support you mentioned, BTW. If anything, allocator crates are more "special" that GC crates -- GC crates look like any other crate, but allocator crates have some special annotation.
I think I read a preprint of that paper, not sure (cant read the paper from here right now). It addresses the other half of the rust GC problem -- one half is designing a safe GC interface (which is solved by rust-gc or these hooks), the other is writing a good and useful GC algorithm.
In any case looking forward to it.
I can write a linear algebra library that gives you Vec3d and Matrix4d and the ability to multiply/add such types using regular multiplication operators. I can also write a Gc<T> library that lets you wrap some values in a GC heap allocation, which will have some extra stack maps being generated. It doesn't feel much different to me, both are equally worthy of being called libraries.
Anyway, expect a blog post soon. :)