What you are suggesting is that we use a GC in
unsafe code. This is odd, because we have
unsafe in GC languages to do the opposite: to be able to ignore the GC.
The niche case you're suggesting is that where you need to use
unsafe to describe something that cannot be described with lifetimes due to restraints or inconclusive determinations on behalf of the compiler.
If your structure can't be described with lifetimes there is a chance your problem is not meant to be solved that way in Rust. And even then, if I really wanted to build such a structure in safe Rust, I can. With structures which mimic a GC. Those are
std or similar structures from other crates.
If a GC were heavily integrated into Rust (Even in an
unsafe context), then chances are it wouldn't interact nicely, simply because a static, compile time construct like lifetimes is created for the sole reason of doing what a GC does (memory safety) without a GC.
It also seems you're under the impression that
unsafe Rust requires you to manually de-allocate things and go back to the archaic
free everywhere ways. That is not true. Everything I use in safe code I can use perfectly fine in
unsafe code just enables constructs the compiler cannot prove to be safe to use in a given context. For example: raw pointers are untracked and cannot be proven by the compiler to be safe to dereference. Or an intrinsic function that is simply too contrived and niche to the language to have the compiler try and decide when it's safe to use.