Personnally, I would like override to be used when implementing interfaces too, because there is really some hooking happening (and thus hijacking risks), regardless of the presence of a previous method or not.
If the problem is that you may have a method witch overrides an abstract class CÂ when the overide keyword was meant for an interface before restructuring, well, that can happen. Let's take your example: interface I { void foo(); } class C:I { override void foo(); } -> becomes -> interface I { void foo(); } class B:I { override void foo(); } class C:B { override void foo(); } // left by mistake Maybe foo was left by mistake, but from the beginning (before creating class B), the method was meant to override I, so it must not be that bad. Moreover, the override keyword is present, so you should be careful when looking at class C. This seems to me to be less important that implementing an interface by mistake (apparently not to everybody). Anyway this could happen anyway if 'I' was an abstract class at the beginning. If you are concerned by knowing exactly what you override (ant it's a good thing) when you use the override keyword, the langage should help you with an argument to the override attribute: interface I { void foo(); } class B:I { override(I) void foo(); } class C:B { override(I) void foo(); } // left by mistake ^ error: foo() is overriding B.foo() abstract class B2:I { } class C2:B2 { override(I) void foo(); } // would works fine class C3:B2 { override(B) void foo(); } ^ error: foo() is overriding I.foo() The argument to override should be optionnal, so that every good code will not be broken. Cheers. -- Christophe Travert