> To bind two completely unconnected things together on a single media you
> still need explicit permissions from both copyright owners.
Of course, to redistribute something you need permission because copyright restricts redistribution. And of course a license that grants you permission to redistribute one way MAY restrict redistribution in other ways: this is not uncommon even. As you point out, many licenses such as Adobe's allow you to use the software only if you obtain it directly from Adobe; you cannot give the software to someone else. THAT is why you cannot get a CD with both Linux and Flash bundled on it; it has NOTHING to do with the GPL. You can't distribute a CD that contains nothing but Flash, even... unless you've executed a different license agreement with Adobe.
I guess we can disagree about whether the "mere aggregation" clause is necessary; my belief is that it's there merely as a clarification and that even without it the GPL implicitly allows aggregation. Maybe not. Either way it's moot because the clause DOES exist and so both the GPL and LGPL make explicit that aggregation is allowed.
Your argument was that because the kernel and libc would be developed together, somehow they would not be able to take advantage of the "mere aggregation" clause any longer. In order for that to be the case, libc would have to become a "work based on the Program" (e.g., the kernel); as long as it's not a work based on the Program, it can still take advantage of "mere aggregation". Whether or not libc is a "work based on the Program" depends on whether it is a legally derived work or not; it has nothing to do with the development model.
In other words, as I mentioned before, if libc developed by GNU is not considered to be a derived work of the kernel (and hence can take advantage of "mere aggregation"), then why would libc developed by kernel developers be a derived work (and hence NOT be able to take advantage of "mere aggregation")?