One of the many things I love about VB is it's explicit interface mapping. It's the beauty of declarative coding that not only allows for flexible mapping but also makes the code explicit. You don't need to know the intimate details of a given interface to work out which methods it actually maps to, because the member declaration explicitly states it. Let's say for instance you have an interface that has a Foo method such as Foo(gizmo). And in your code you have Foo(sprocket), Foo(Of T)(T), Foo(gizmo, gadget) as well as Foo(gizmo) . You of course know which one gets called via the interface don't you ? Well yes in VB as it stands today you do.
So explicit interfaces are a good thing. There are however times you want implicit interfaces, that's why they are on my feature request list (item 11). Consider the case where you have code generation and you want those generated members in your class to form the interface contract. Today in VB you can't do that in the partial class as you can't over write the generated members. So there's a mismatch there, and implied interfaces would fix that problem.
What Paul Vick is suggesting however goes beyond just fixing that issue, it instead breaks the IDE and code reading experience by making Implements no longer mean that the members are implemented explicitly, and also adds silly restrictions on to what can be implied and what can't, causing yet another set of problems. Even just the simple task of typing Implements IFoo becomes complicated as the IDE would have to ask you if you want to define that explicitly or implicitly. Code maintenance would also become more of a nightmare as you wouldn't know if explicit or implicit is being used (at least not from the class declaration)
The biggest issue with the Implements keyword re-appropiation is that it risks breaking existing code. Paul suggests a limitation be placed on VB to get around this issue, that being that no base class members can be part of an implied interface. So what we have here is an oversight in the original language design of VB.NET, and rather than break that, and rather than introduce a new keyword, the language would be "forever more" crippled in regards to implicit interfaces : You'd never be able to refactor a common method into a base class without risking breaking an implied interface. This fragile tenure which is meant to fix an issue of designer generated code not interacting well with your code, relies that that designer generated code doesn't have any of those methods in a base class.
Or to put it simply, re-appropriating a keyword usually is a bad thing, and this definitely applies here. I doubt this will change though as I know I have definitely raised this very issue with the VB team before, and in regards to implicit interfaces, I know, as my feature request list lays testimony to, that I have suggested what I believe is a clearer syntax that doesn't have the crippling side effects Paul's re-appropriation would have :
Class Foo
Implies IComparable(Of Int32)
Non breaking, not limited, and a much cleaner experience in the IDE
Oh, and while I'm talking about interfaces, I sure wish they would put relaxed interface implementation on the table. Erik seemed to get it when I talked about it, but I think he's moved onto to democratising the cloud these days :)