Getting a web framework into the standard library is something I want to get working, along with a windowing library.
Currently we need to get a stackless coroutine into the language, actors for windowing event handling, reference counting and a better escape analysis story to make the experience really nice.
This work is not scheduled for PhobosV3 but a subset such as a web client with an event loop may be.
Lately I've been working on some exception handling improvements and start on the escape analysis DFA (but not on the escape analysis itself). So the work is progressing. Stackless coroutine proposal needs editing, but it is intended to be done at the start of next year for approval process.
Indeed the GC is just a library with some helpful language hooks to make the experience nice.
If you understand how it's hooked into, it's very easy to work with. There is only one area of the language related to closure context creation that can be unexpected.
The following statement originates from Adam Wilson who is heading the PhobosV3 project, and I will second it.
The issues you have are examples of known problems that PhobosV2 has suffered under. Coroutines, for instance we would like to have in language, a proposal (me, not Adam) have already made one, but it's sitting till next year. Naming and interfaces issues are a big part of what will change in PhobosV3.
LLVM can do an awful lot with SIMD that isn't visible in clang.
We have experienced this with LDC in D.
What I've been told is that LDC produces better IR than clang (I haven't compared, I only know that LDC is practically magical from both mine and other peoples experiments).
About the only thing I've seen that has problems with inlining is inline assembly. Intrinsics are fine (which you don't need thanks to vectorization being practically magical as long as you do some annotations like assert and get the memory layout right).
I wrote one back in 1983 or so for 16 bit DOS, too!
A few years later, I was at a C++ conference where they asked me to sit on an "Ask us anything" panel. I was there along with the developers of Microsoft C, Borland C, etc.
The first question was "do you still ship a version of your compiler that will run on a floppy disk system?"
Vendor 1 said sure, and launched into a long description of how the files could be shuffled about on the floppy to make it work.
Vendor 2 said sure, and launched into ...
My turn. I said sure, and said the floppy disk version costs $200 and comes with a hard disk drive. (That was the price of a hard disk in those days.)
That was the end of that, I never heard that question again from anybody.
Memory safety is broken up into a bunch of different categories. It isn't just one feature.
Yes D uses the GC for lifetime issues currently, but it does not need it for doing bounds checking, escape analysis or preventing common issues surrounding pointers. All of which are very useful things to have with or without the GC.
Just those features alone would prevent some pretty big name issues that have cropped up in C code over the years.
That work contributes to static analysers' data flow analysis algorithms and is very widespread, even if it's in a limited capacity.
C#, gcc, clang, and even dmd, with my fast DFA engine, utilise it.
We can't all be using Astrée, far too expensive ;)