I suspect that this is about the requirements being inferior in comparison to some superior, lofty requirements that the author has in mind; that's what is meant by "incorrect". There is some underlying theory which is applicable to the requirements for a given language feature, and those requirements are "incorrect" because they ignore that theory and specify some sort of hack.

The unsound type system is hardly simple at this point, and type errors are a pain because they aren't modularized very well (and structural type errors tend to cascade quickly). Still, it beats the alternative.

- You can accidentally implement an interface.

- Lack of a proper ownership model can lead to unexpected results, which leads to bugs. Consider e.g. growing of slices:

https://play.golang.org/p/3qfd5B8_ktK

- nil is not equal to nil:

https://golang.org/doc/faq#nil_error

(Obviously, it is is easy to move the goalposts without a proper definition of 'correctness' ;).)

Go is quite a stable language. Well-specified, rigorously tested, and conservatively updated.

I think all the behavior you listed is well-defined, albeit perhaps unexpected.

Lack of generics doesn't make code incorrect. Less clear maybe, or easier to make a mistake. Or clearer and a lot more code.

I guess you could argue that it makes writing correct code harder?

I think he's stretching the definition of "correctness" past the breaking point, but that clearly was what he meant.