One thing often missed in discussions of insensitivity is the very different user scenarios of "interactive" vs. "written once to be read many times". Insensitivity tends to be more popular in the interactive/IDE/REPL setting in the same way as TAB/whatever auto-completion. My first encounter with "style insensitivity" was actually the Z Shell's `setopt`, but there are _so_ many settings I doubt many people use it interactively as opposed to shell init files. Anyway, the increased expressiveness of sensitivity (with its precision burden) tends to win in the write-once/read-many settings where the writer wants to emphasize certain identifier roles like "typeness", "mutability", and so on. Maybe some meta-trait is so important that ALL_CAPS would be appropriate.
In a write-once/read-many setting, almost everyone wants _some_ convention with redundant cues, much like almost everyone wants color syntax highlighting. There is even `nim c --styleCheck:hint` and first-letter case-sensivity. People just differ on what the convention should be (often based on psychological accessibility of misunderstanding risk based on individual or organizational history). Flattening the space into insensitive land as Nim does now is one way to avoid convention wars/make code look the same locally, but it contracts what conventions are possible, thus limiting expressiveness. Another solution to the "use library code according to my local style" might be staying fully case/_-sensitive but adding a user-defined but compiler-enforced style system. Eg., a module could maybe declare (or `include`) its identifier styles at the top, maybe even only ever on the very first non-comment line. "types are like this, fields are like that, compile time consts are like this". Then the compiler can maybe translate foreign<->local styled idents or both to some lingua franca. The compiler might also squawk (a generalized `nim c --styleCheck:hint`) if the local module violates its own declared conventions which I suspect would be a popular feature for those passionate about identifier conventions. This is not unlike `nimsuggest`-based semantic code colorization which can make a `template` a different color than a `proc`. There may be trickiness to unambiguous translations that might limit this approach. Admittedly, it also creates some whole new sub-syntax to declare identifier styles based on roles in the code. There may be other problems with this idea I don't realize. I do kinda doubt it would make Nim seem less weird to developers, though. Personally, I like just full sensitivity best.
