Interface comparisons check both, the value and the dynamic type. Describing that as "comparing vtables" is misleading.

It the types don't match, the operands are not considered equal. Type and value have to match for two interface values to be equal. How does that not make sense?

For mismatched dynamic types you can't meaningfully compare the values in the general case, so of course you need to consider types.

If x.Foo() and y.Foo() do different things and return different values, clearly x != y, and golang needs some kind of SQL-style is-null check rather than using equality to check for null.

But dynamic dispatch on "what type of object do I not have?" is still a damn weird thing to want.

Having dealt with languages that don't, I much prefer ones that do. The thing is, most languages DO basically check vtables, in that 2 values with different types will never be equal (unless there is implicit casting or some kind of equality override). For instance, 1 == "1" is valid, and true, in PHP, even though that is less then ideal. The difference, of course, is that most of those checks are done at compile time in many languages. Go will do some checks at compile time, but it's specifically unable to do some of them due to the "dynamics" of how interface variables work.