You "imagine" incorrectly. A functioning Obj-C requirement requires a runtime. Currently that runtime (libobjc) is written in C, and it requires a C library to function. Yes, you can rewrite those portions to use only functions available in kernel-land, but it is by no means "easy" as you suggest.
This just goes to show you don't understand compilers.
No, admittedly, I don't, at any more than a basic level. But you're still wrong.
Try compiling, linking, and running an ObjC program without the ObjC runtime. See how that fails. See how long it takes you to write a minimal runtime that can run your program in user-space, and then kernel-space. It won't be quick.
Try compiling, linking, and running a plain-vanilla C program without the "C runtime" (I guess you mean a combination of libc, libgcc, and crt.o, basically what you get when you pass -nostdlib -nostartfiles to gcc). Yep, that'll fail too. Then get it to compile and run anyway. Not that hard.
That's* the difference I'm talking about.
At the very least, kernels like Linux and Mach/Darwin already have kernel-friendly replacements for the libc functionality they commonly use. Doing something similar for ObjC would be time consuming. Certainly it isn't impossible, but note that I never said that: I merely pointed out it wasn't easy.
C hardly requires it's runtime. Objective-C without the runtime is just C, if you write the runtime, GC, and other low-level system components in the C subset of Objective-C you are just writing the kernel in C.
This is in the original context of how all systems will be written in "GC enabled system programming languages". If the language is not GC enabled due to missing a runtime or w/e then the technicality isn't relevant.
The problem, is that at the end of the day, some code somewhere is going to have to deal with resource allocation. Generally speaking with all the other fluff aside, an operating system, fundamentally manages and multiplexes resources. It's naive to think that resource management would be best done in a language with automatic GC. Somebody
I don't doubt that C is not the systems programming language of the future. But it's not going to be done in a system that's based around automatic GC either.
You use the word proven as if it means something. The work you list is no more proven in terms of building production systems than any other research work.
Additionally, I find it interesting to note, that if you had in fact been very familiar with all the work you mention. You should actually have noted that many of these systems go through significant effort to sidestep the GC.
It is proven, because groups of people went through the effort of spending time and effort implementing those systems and used them for daily work as well.
It not just talk about some guys showing up papers at OS geek conferences.
The Oberon Native for example, was for long time the main operating system at the operating system research department at ETHZ. Most researchers used it as their daily OS for all tasks you can think of.
Don't forget that UNIX was once upon a time a research operating system, and took a few decades to have industry impact.
New ideas take time to mature.