There one big issues, where I think D might make progress:
Combine GC and non-GC in a single application. This would be great for game programming for example. Handle audio and video in a soft-real-time non-GC thread. Handle other stuff like game logic in a GC thread, such that it is easier to write. The hard part is that GC usually requires stop-the-world. You can currently do this [0] in D, but it is error prone. Rust tackles this problem from the "other side": First make it safe, then possible.
The idea is to eventually have a Gc<T>-like type, like Rc<T>, which can be used on specific things. It will interact fine with the regular heap, so `Vec<Gc<Foo>>` where `Foo` contains a `Box<Gc<T>>` will still work.
You can then selectively apply this Gc<T> to things which need it. For example if you have a large graphy-datastructure in your code and don't want to bother with weak pointers. Or if you are doing FFI with a language that does have GC.
Rust itself would not have the Gc<T> type in the stdlib, it would only contain a couple of traits and compiler intrinsics that are useful for a GC. (The idea is to be able to turn on LLVM stack maps and use it for GC rooting). So you can write a gc for your specific use case (even if that use case is just safe bindings to a different GC from a runtime you are interacting with!) and it should work. In fact, in the design so far it seems like multiple GC implementations will be able to exist in the same application, and perhaps even safely interact (you can control whether you want this to be possible using the type system; I'm not sure if there is ever a case where this would be needed)
This would of course, still be safe. It would not be possible to violate GC invariants using safe code, nor would it be possible for the GC to violate regular safety invariants.
My biggest concern with the Gc ideas floating around Rust right now is that they may infect your program through dependencies.
I guess I'm mostly worried about Gc being used by a large number of libraries, to the extent that it might not matter if stdlib implements it or not, because by using some very popular library you'd end up pulling in this runtime dependency.
Part of me loves the flexibility this will bring to application design, but it could be a slippery slope.
If such a popular GC-using dependency came into existence, then there would surely be demand for a drop-in replacement that didn't use GC.
Remember, even the proposed Gc<T> type provides very little in the way of ergonomics (at least compared to garbage-collected types in pervasively-GC'd languages). Essentially it would just be a souped-up Rc<T> with no need for weak pointers to resolve cycles. Alternatively, it would only be used to interoperate with a foreign codebase that already uses GC, like SpiderMonkey or V8.
Given that people tend to only be writing Rust in the first place if they put a large degree of value on performant solutions, I'm not too worried about the library ecosystem suddenly sneaking in GC everywhere, especially since the Rc type is already halfway to garbage collection, and I don't see it used unduly in the wild.
It's not going to be something considered idiomatic, especially in a library. Rust support quite a few things which you're not supposed to use other than in exceptional circumstances (e.g. catching/recovering panics -- there has been no slippery slope yet).
Nor will the stdlib expose a GC API. I do intend on writing an example GC for this, but really each use case will probably need its own special GC implementation; since they are special use cases.
That's not a decision to take lightly.
I don't think GC will be something that can be silently pulled in, either, since you will need to change your codegen flags at the top level. This could be abstracted away by cargo, but it might be better if it wasn't; and you have to explicitly tell cargo in the toplevel toml file that you want GC to be on (and get a compile error if you try to compile without those flags).
==================
Also, the Rust community seems to be very careful about unnecessary costs. Even Rc<T> isn't used much, and when it is, it seems to be used at the application (not library) level.
When I have to box a closure or iterator in Rust because `-> impl Trait` doesn't exist (where you can return anonymous types by specifying the trait they implement), I feel so annoyed by the cost. As do many other Rustaceans. In reality, this is a pretty rare thing to do and the costs are negligible; but it feels annoying to not have the best performance. In such an environment, I doubt a library that frivolously uses GC will survive.
Seems to go very much into details about syntax bike shedding but not saying much about the more "global" design differences.