I think "natural" is a bit loaded, there is native support in the frontend for doing both. You have to go out of your way to annotate functions with @live and it is still experimental(https://dlang.org/spec/ob.html). The garbage collection is natural and happens if you do nothing, but you can turn it off with proper annotations like @nogc(https://dlang.org/spec/function.html#nogc-functions) or using betterC(https://dlang.org/spec/betterc.html). There is also @safe, @system and @trusted(https://dlang.org/spec/memory-safe-d.html).

So natural is a stretch at the moment, but you can use all kinds of different techniques, what is needed is more community and library standardization around some solutions.

D is as memory safe as Rust is, when you use the garbage collector to allocate/free memory. If you don't use the GC in D, then there's a risk from:

    * double frees
    * memory leaks
    * not pairing the allocation with free'ing

In other words, with D, there is no point to using the borrow checker if one is using D's GC for memory management.

You can mix and match using the GC or manual memory allocation however it makes sense for your program. It is normal for D programmers to use both.

I don't think gradual types are as holy grail as you make them out to be. In gradual typing, if I recall correctly, there was a large overhead when communicating between typed and untyped parts. But further

But lets say gradual memory management is perfect, you have to keep in mind the costs of having GC + borrow checking.

First thing, rather than focusing on perfecting GC or borrow checking, you divert your focus.

Second, you introduce an ecosystem split, with some libraries supporting GC and others supporting non-GC. E.g. you make games in C# and you want to be careful about avoiding GC, good luck finding fast enough non-GC libraries.