If they're aware of how other languages either handle these issues or suffer the consequences of not handling them, then it sure is odd that they consciously decided to introduce the same issues into their own language, only to fix them down the road.
Given Go’s success, it seems like fixing certain footguns much later actually worked out pretty well for them? That doesn’t necessarily mean it was right, but it was perhaps not as big a deal as some people assume.
Sum/Product types. Generics/type-parameters. Bizarre handling of nil in places. Error handling that’s like some deliberately crippled version of a Result<T,E>. The absolutely unhinged decision about zero-value-defaults for types. I’m sure other people can think of some more, but that’s the ones I can think of off the top of my head.
Non PL theory but related: incorrect implementation of monotonic clocks, and then refusing to fix it because “just use google smear time bro”.
But they’re like, genuinely wild decisions? Unhinged is a great description!
The error design can return the value, or an error, or both, for some inexplicable reason and you can check it - or not - and if your function returned some indication of severe error, and you happen to not check it, you can totes just continue your program, in who knows what invalid state. Oh and also, because the devs are apparently deathly allergic to abstractions of apparently kind, you’ve got to do this janky little if err != nil check at. every. single. point. Which occludes your fundamentally important logic in pointless line noise, with zero opportunity for streamlining or improving the logic or guarantees.
There's nothing casual about Go's approach to language design, and I haven't seen any evidence that they're unaware of what other languages do.
I also haven't seen much criticism of languages other than C++ or Java.