That they are technically different nils if you split hair enough really has no bearing on the user hitting those issues, with no real way to work around them, and no warning from the tooling.

And your explanation does not really hold in actuality:

    type DoesAThing interface {
        Thing()
    }
    type ThingDoer struct {
    }

    func (td ThingDoer) Thing() {
         
    }

    func WillPanic() {
         var thingDoer *ThingDoer

         var someThing DoesAThing = thingDoer 
         someThing.Thing()
    }

There is no situation in which calling Thing() on a ThingDoer will break, but Go's author have decided that implementing an interface on a value also implements it on the pointer, I never said to do that and carefully did not do that.

This means when you assert that

> the nil is an invalid implementation, not because it is an invalid Go value, but because it is an invalid implementation of the interface.

The design of Go forces that lie on you, you have no way to opt out of it. If you implement interface methods on a value receiver, that lie will be forced onto you with no recourse. If you implement interface methods on a pointer receiver, then that lie will still be forced onto you but give you the option of... defensively ignoring and maintaining garbage state (à la ObjC I guess).

"That they are technically different nils if you split hair enough really has no bearing on the user hitting those issues, with no real way to work around them, and no warning from the tooling."

They have different types. This is not splitting hairs.

"The design of Go forces that lie on you, you have no way to opt out of it."

No, it doesn't. I've been programming in Go for about 8 years now, and I do not face this problem, because I do not lie in my code this way. My own experience is constructive proof of my point. That it, it falsifies your point, if this was "forced" on me I'd be encountering this problem. It is not a problem you have to have in Go. I can and have rewritten any code that has this problem when people post their code where they are "forced" to have this problem, and this is the cause every time. It is a result of bad programming decisions. Do not create objects that can not fulfill their contract, and you won't have problems with them propagating through your code.

(I mean, I'm really shocked at how much this angers people. Who is really advocating for "Create whatever garbage you want where ever and get angry at the downstream code when it can't pick up the pieces?" I mean, sure, it's a common style de facto, but who is advocating for this?)

Go is far from the worst case of this, the dynamic typing world affords code at scale that does this so much that it simply becomes a fact of life. It's the biggest reason I've come to loathe writing any code at scale in dynamic languages.

I think people might just be surprised at the idea that there should never be any method that takes a struct by value instead of a pointer (because someone could create an interface containing that method) and that every method with a pointer receiver must handle nil.

The official golang tutorial explicitly does not say "never use struct receivers at all" even though using them is "lying."