Earlier quoted context omitted.
nil is always equal to nil. You might be confusing it with comparing a nil pointer to a pointer to a nil pointer, which are not equal.
The nil-interface wart actually does result in comparison issues, and it's something that trips people up all the time: package main import ( "fmt" "io" ) type Thing struct{} func (t *Thing) Close() error { return nil } func main() { var x *Thing var y io.Closer = x fmt.Printf("x == nil -> %#v\n", x == nil) // true fmt.Printf("y == nil -> %#v\n", y == nil) // false } Here, both x and y are conceptually nil, but y can…
Your mental model for an interface is incorrect--an interface is just a pointer. A pointer can be nil, but some pointers point to other nillable types. If we paper over this for nil checks, we destroy states that are semantically valid/important. Abstracting as you propose creates more surprising behavior than it fixes. On the other hand, all it takes to avoid the problem altogether is the understanding that interfaces are just (fat) pointers.