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).
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.
We do our best to ensure everyone feels welcome to join in. Of course none of us have social media training and are just doing our best.
If something is going down and we are not taking action it may be because we are not aware of it being problematic and are always open to hearing complaints as they come up!
Lots of stuff exist specifically to help with onboarding people into the community. Like the recent announcement of adding a C parser into the frontend.
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 ;)