I'm the first to argue that Go is "most reasonable" all around.
Even things which are technically wrong and _could_ have been done differently are still reasonable.
First and foremost because sometimes the alternatives would have meant breaking backwards compatibility (or at the very least forcing people to hassle with migrating code with "editions", which are probably better left for more impacting problems than "what if a new OS comes around")
That said, I think it's important to call out design mistakes when one sees them (as long as one engages constructively with them instead of just throwing a random "Go is magic/sucks/etc" without putting things into context, like how do other practical languages fare on all the metrics combined)
Something I have found surprising and tripped over is that the commands are not the same as the language and the Go team generally does not scrutinize changes which break invocation of commands in the same way that they do the language via the Go 1 compatibility guarantee.
I think overall the semantic filename build constraints `_GOOS_GOARCH` as well as `_test` suffixes provide real value in that I immediately know that the file is build constraint guarded, and it aids my ability to read/browse code greatly. If that information were not encoded in the filename, but only in build tags in each file, then it would be a fairly significant hit to my productivity. I can't see any alternative that is not more complex, and I have issue finding that complexity justified.
I think there is a tradeoff here, the Go team knows it, and that in practice the tradeoff is worth it. There are many such things in Go, tradeoffs of purity and theoretical issues for the sake of practicality, and by and large they're okay.
I also like the use of the file name "pre-extension" to categorize files.
There was a way to have the cake and eat it too which is: forbid _ inside the file name other than the extensions that have a well known meaning and treating the others as reserved.
Well, if the file got ignored that would be very surprising and a source of frustration indeed
A clear error message that explains that go source files cannot have underscores in them other than the supported suffixes (and a link to a page that documents them).
If you do that since the beginning then it's easy and painless.
The problem is: what do you do when you haven't thought of the consequences of one convention? Do you fix it later?
I'm happy with the current Go trade-off. This detail isn't worth fixing.
But it's nevertheless interesting to use as an excercise to see how it could have been done in a way that preserves all good properties and is also future proof
