In my mind, this difference is critical, because at a binary level (byte code, IR, assembly, what have you), the actual human-readable names don't matter. At the binary level, the interface essentially is nothing more than a bunch of bytes representing offsets into other byte arrays representing code, and yet more bytes arranged at other offsets representing arguments. Whether that code was generated from "File.open(fname)" or "new File(fname)" or "open(fname, O_RDONLY)" does not matter at all, because the final machine code (on x86) is essentially "mov al,0; mov ah,3dh; int 21h" (or the binary representation thereof).
As such, you could generate a binary that calls code represented by an API without using the API at all. But of course, nobody really does that because human-readable "new File(fname)" is so much more expressive (and more important, much more readable) than they bytecode for "new #3; dup; aload_1; invokespecial #4". There is very limited potential for creative expression in a sequence of bytes and offsets, which is why it differs so greatly from APIs from a copyright standpoint. However, it is the bytes and offsets that is actually makes computer systems interoperable, not the names and organization of the APIs. Unfortunately, the Sega/Sony caselaw seems to exempt the former from copyright law, but the latter is what Google copied wholesale. Now Google, EFF et al are trying to conflate the two. (Of course, the fact that Android is not binary compatible with Java either is another hole in Google's own defense.)
> ... APIs are not code at all...
One could make convincing arguments both for or against that, but it does not matter from a copyright perspective. From what I can tell, anything that is "written" and can have "creative expression" is protected by copyright. My point is simply that, unless some exception is carved out for it, APIs being copyrightable is currently completely consistent with what copyright is intended for.