I guess you can do that, but what stops people from just continuing to do what they're already doing. They'll argue their sources aren't GPL, and that they're doing nothing wrong. Simply having some other piece of code apply a symbol to them doesn't really change the legality of the situation one way or another, unless it is in the sense of being more up-front about your claim that this infringes.
Let A = 10k lines of code. Let B=200 new lines of code intended to be combined with A. Let C=A+B. The argument people are going to make is that B is NOT a derivative work of A, but C is. By that logic the in-memory linked (that is, with addresses resolved by the dynamic linker) non-GPL module plus the rest of the kernel is a derivative of the kernel, but the non-GPL module files on disk are not. Since nobody distributes the in-memory image they would argue this is not a GPL violation.
By this logic there is little distinction between the LGPL and the GPL. Clearly this is not the intent of those who use the LGPL vs the GPL, but ultimately what matters is what a court decides. Can a copyright holder restrict linking?
And what is linking, anyway? One program exports a list of symbols. Another program imports them. If you don't buy the whole SCO argument the names of the symbols themselves are an interface and aren't copyrightable, so their inclusion in the linking software doesn't make it a derivative work. Then a linker goes and resolves a bunch of function calls between them, which isn't really a creative work.
Personally, I'd prefer that things work the way the way the kernel team intends them to work. However, I'm not certain a court would agree. If there actually is any testing of this in court I'd be interested.