This is simply a judgement call of the compiler authors to name the command "lowercase gcc" to avoid inflicting caps lock or shift on people, but it's a judgement call the case-sensitive file system enables rather than blocks.
When I say `whence -m '*[A-Z]*'|wc` in Zsh. I get about 200 commands that have mixed case. Of course, probably close to half of those are my own things. But yeppers, sensitivity indeed means that you're forced to spell things one way. :-) Some of my upper case things are wrappers around commands like `Xz` around `xz` to avoid trivially accidental recursions. (Yes, I know there are other ways to do that. It's just another example.) I came up in physics/math not CS and there adjacency implies multiplication and other dense notations lead to font switches and boldface switches and so on all to designate extra variations/bits. So, my brain may just be more tuned to use case to distinguish as opposed to being annoyed at remembering how someone else cased something. I mean, this has never been a deal breaker for me, personally and I even made cligen one step more insensitive (dash/'-' insensitive), but I doubt it will ever "not come up" or ever not be seen as a questionable choice. Most of Nim is super flexible at little cost (or really negative cost, large gains), but this particular feature seems to "cut both ways" \- it kills name convention wars by killing distinctions people like to draw. Ident convention wars are a drag, but they're also kind of a "social problem people seem to want to have". They want to say things with these case-bits, and then the language prevents them from saying it - whether mratsim's mutability or other distinctions. For most languages I have seen, the standard library just "sets the tone" and 90% of people go with that tone/style in _many_ "stylistic" ways beyond just casing (e.g., short local variable names, indentation, comment density, lengths of functions, modularity styles, documentation verbosity, etc.). The pickiest people are often that vocal 10% minority. I don't think we lose people for the feature, but I think it's really hard to know how many we fail to attract. I think resuscitating the mode where case could be optionally strict and making sure the main stdlib compiles with it would go a long way to silencing such complaints. "Just opt-in if you want that with this one-liner (or compiler option flag)!" Then maybe Nim coders only have to be style insensitive when they are cooperating with other Nim coders. I'm not sure what instigated killing that mode. Were 3rd party library writers getting a lot of annoying issues filed for "can't work in strict case mode"? Or were there other interoperation problems? In any case, a questionable default seems fundamentally easier to defend to outsiders than no choice at all. It's your compiler/language (and a great one! and thanks!) and ultimately your judgement call, as always. It's a lower priority than many other things on my own list, but I have no idea how high it rises on the lists of all those Nim fails to attract.
