Same workflow here, and it's become a breeze with autofix, rebase --update-refs, and a small command to push the whole stack.
I'm using magit, so I directly see what could not be matched and remains staged.
Yes, I empirically found the hunk-based approach of git autofixup to work more reliably. I use it via magit.
Paired with rebase --update-refs, it's particularly helpful to automatically fixup stacked branches.
You loose builtin arrays and hashes and need to use a container library instead. Same goes for newing aggegates which can be replaced with smart pointers.
Escaping closures (delegates) no longer works, but you can explicitly capture context in a struct.
Those choices for builtin language features date back to the early inspiration from Java, but are increasingly being replaced with library implementations.
We've added escape checking to the type system last year, and are currently working on safe aliasing (preventing use-after-free).
So yes, atm. when opting for @nogc you're somewhat at the frontier, and it's mostly a choice if you have time, hard requirements, or am very practised.
Avoiding most (but not all) GC allocations is already widely adopted in D's community though.
You don't have to restrict yourself to betterC to use manual memory management. BetterC is mainly targetted at embedded programming and to port components of existing C applications. Malloc vs. GC vs. stdx-allocator is a separate topic, though betterC doesn't link with the GC by default.
Yes, if you're willing to spent some effort on it.
Somewhat simpler you can just avoid most GC allocations so you don't run into any performance issues with the GC.
http://dlang.org/blog/the-gc-series/
Mind to share why a GC seems to be unaccceptable for you?
The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall, hence further work on GC improvements was deprioritized.
http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/
The problems are known and indeed a full rewrite on this ancient GC would be in order. Since D 2.072.0 it's possible to link and use different GCs, so a faster one could be written as an external library which would be a very welcome effort.
https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-ad...
I'd be interested in experimenting with a Connectivity-Based GC (https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf), leveraging type information to do partial collections.
Write barriers come with a performance penalty (~3-5%) that we don't want to impose on people using deterministic memory management, but most GCs capable of performing partial collections, e.g. generational GCs, do require write barriers, Connectivity-Based GCs do not.
For the time being the pragmatic advise is to replace major sources of GC allocations with deterministic memory management when the GC heap grows too big (~1GB) and performance becomes a problem.
So far this hasn't prevented various people from writing extremely fast D programs.