"The only thing that matters from a licensing perspective is whether the libc is legally a derived work of the kernel (or vice versa)"
Your message appears to embody a commonly repeated piece of misinformation about how copyleft licenses work. I'm responding in order to squelch its continued dissemination, not because I disagree with your conclusion.
"Is foo a legally a derived work of Bar" is almost never a important question with respect to license compliance of bundled software.
The relevant software license sets out conditions under which is can be lawfully reproduced. Absent the license you can not lawfully reproduce the software. A license for Bar might specify that you can only reproduce the software on a computer that doesn't contain a copy of nethack and the requirement would be perfectly enforceable. Not become nethack is somehow a derivative of Bar and is thus tainted by bar's license but simply because the license of bar says so, and you're distributing bar so you must abide by the license or infringe. If you don't like it then you can opt not to distribute Bar by doing so escape its requirements.
The legal criteria for how copyright encumbrances flow from place to place are relevant in some contexts, but usually not in the context of bundling because no 'flowing' is required: When you bundle you must obey _ALL_ relevant licenses.
The GPLv3 carefully avoids any mention of the word "derivative" in order to avoid this confusion with other uses of the heavily overloaded term.
So in the case kernel and libc you have to actually look at what the licenses require. You can't just depend on some extenal notion of a legal definition of a derived work to somehow bound things, because it wouldn't. Considering that the distributions bundle these things already I think it's safe to say that there currently isn't a problem. It may more complicated as each of the packages is intimately extended with code existing in the other.