The rest of my comment fairly specifically covered that: Go nil pointers don't have runtime types (like C), Go nil interfaces sometimes do.
In any case, pointers to pointers with different types seem likely to be a strict aliasing violation in C.
> In any case, pointers to pointers with different types seem likely to be a strict aliasing violation in C.
Surprisingly, no, at least not in similar context. For example, it's perfectly legal to cast a pointer to a struct to a pointer to its first member - it's specifically guaranteed that this works as you'd expect. This is often used when emulating single-inheritance OOP in C - your "base class" is then the first member of struct type, and this lets you upcast and downcast with impunity.
Casting pointer-to-struct to pointer-to-field is fine, yes, but is it legal to cast pointer-to-pointer-to-struct to pointer-to-pointer-to-field? (I genuinely don't know the answer to this.) The former results in a new (temporary or otherwise) value with a new static static type, independent of the original, while the latter does not, and so is the interesting one. In any case, note that Go also has something a little similar, with its anonymous fields approach to composition.
However, that's not still at all the main point: there's actually not that much difference between how C and Go behave with compiletime/runtime types.
The point, I think, is that this type information is carried only at compile time on the binding, not at runtime on the value itself. If you have multiple aliases to the same null value (e.g. via references or pointers to pointers), the behavior will change depending on which alias is used. Not so in Go.
Of course, this is also true for non-null values in C++, when methods are non-virtual, so...