Consider the following case:
   public interface I1 { default public void m() {}} 
   public interface I2 extends I1 { public void m(); } 
   public class T3 implements I2 {} 

Call site: T3 { invokestatic T3.m()V T3 } 

NB: T3 isn't marked as abstract.

VM: IncompatibleClassChangeError: Expected static method p1.T3.m()I
JVMS: AbstractMethodError should be thrown

Please, note that if I1.m is absent, AME is thrown as expected.

JVMS-5.4.3.3. Method Resolution
"[I]f method lookup succeeds and the method is abstract, but C is not abstract, method resolution throws an AbstractMethodError."

JVMS-6.5 invokestatic.
"Linking Exceptions
During resolution of the symbolic reference to the method, any of the exceptions pertaining to method resolution (��5.4.3.3) can be thrown.
Otherwise, if the resolved method is an instance method, the invokestatic instruction throws an IncompatibleClassChangeError."

ILW = HLM = P3 

I = H = JVMS violation; though error mismatch isn't that serious, it adds noise into the results and hinders results analysis of default method security testing 
L = L = forbidden by JLS, but separate compilation may be a source of that 
W = M = Incorrect exception can be "translated" if necessary