"Linking" isn't really a legal term either; it doesn't occur either in copyright law (of course), nor does it occur in the text of the GPLv2. It's true that in non-legally-binding prose, the FSF describes the GPLv2 as prohibiting linking with proprietary apps, but the license itself doesn't draw that line. The FSF may have intended to draw that distinction with the LGPL, but that doesn't necessarily mean that it's there in a legally-binding fashion.
("Derivative work" does occur in both copyright law and the text of the GPL contract, which is why the time argument is relevant. US copyright law specifically says, "A 'derivative work' is a work based upon one or more preexisting works." So unless you can argue that OpenAFS has become "based upon" Linux, it's not a derivative work; Linux is clearly not preexisting.)
Are you allowed to write and sell a proprietary LD_PRELOAD for a GPL'd app, that only intercepts standard POSIX functions and doesn't mess with internal symbols at all?
Are you allowed to distribute that library, the app, and a wrapper script? Are they "reasonably considered independent and separate works in themselves", or distribution "as part of a whole" (GPLv2 sect. 2)?
On the flip side, if you sell a virtual appliance that includes the GNU userspace (GPL) and some proprietary binaries, is that considered distribution "as part of a whole" (the appliance), and are you obligated to make your code available under the GPL? Even though there's no linking involved, it's not clear to me whether your code can be "reasonably considered independent and separate" if it's only distributed as part of the appliance.
I think that informed people in good faith can come to different conclusions about what they "reasonably consider" independent and separate. This isn't as obvious as, say, copying-and-pasting glibc's implementation of DNS resolution into your proprietary libc.