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