To the degree the the implementers are also users they carry their implementer understanding into their use. Dogfooding doesn't help when your understanding doesn't match that of your users.

The problem is that the error conditions are relatively rare. Most of the time it doesn’t break anything. So even with dogfooding you can miss it or not see it as a problem early on. But after 10 years of evidence that it was a mistake, that it’s almost never intended, and the fix won’t break much if anything, it’s time to fix it.

No, it’s just an obvious behaviour when you understand how the language works.

"if you learned how this work, then you understand this behaviour"

I disagree with this approach, despite the fact that you can logically explain this,

then it still is terrible design and as you see golang (and c# and other langs) designers realized it too and changed it

So, how can you even try to defend this design when even the designers decided to change it (despite the fact that changing lang is really hard)?

> I disagree with this approach

That is not actually relevant to the point.

> So, how can you even try to defend this design

I'm doing no such thing, I'm pointing out that your reasoning is faulty: dogfooding does not help when the behaviour is logical and obvious to the designer-cum-user, and same with reviewing.

>dogfooding does not help when the behaviour is logical and obvious to the designer-cum-user, and same with reviewing.

While I can agree with dogfodding, then review doesn't have to be done just by the people that are responsible for the design/impl.

You can have external reviewers for (let's call it) sanity check