That sounds more like a legal argument than an engineering one. I mean, who cares what the mechanisms are and what the precise rules and enforcement mechanisms are? The point is there are complicated features that are OK in some contexts but not others, that this varies between problems and between languages, and that some parties make different decisions on how to make use of them even when implementing software for people who take contrasting positions.
I mean... so what? Either Go is good because it lacks exceptions or it's bad for the same reason. And it's either a good decision that it uses a similar mechanism internally or it's a bad one. Both of those are arguments worth having, but they are different arguments and there is no technical reason to demand they be resolved in the same direction.
It is very much an engineering argument, because writing maintainable software requires respecting contracts. If an escape hatch is private, you can't depend on it, because code doing so will break when the hatch changes (and there's no guarantee that it won't).
And my whole response is that that notion of "shouldn't" reflects an aesthetic or moral argument and not a technical one. How Go is implemented says nothing about whether Go is a good language or not.
If I understand you right, your entire argument depends on counting "Go exposes X internal feature" and "Go exposes something equivalent to X internal feature" as different things.
Because demanding Go do either one is an engineering argument.
But demanding the former over the latter is an 'aesthetic or moral' argument.
Well, nobody else is making that distinction! They're only making the engineering argument! You're interpreting their words way too literally if you think they're making the aesthetic argument.
