Case insensitive and _ ignoring identifiers not so much -- they just add mental burden, encourage different styles in the same codebase, make things ungreppable without special tools, etc. And for what?
If the best one can say about a feature is "people still like the language despite it", it might be better to axe it.
Actually, case sensitive identifiers encourage this. If a library uses camelCase but your code base uses snake_case then you will be using a mix of camelCase and snake_case in order to use that library.
That is a real benefit and is entirely the point of this feature.
Which will be totally fine, as it involves different variables / things pointed at.
Whereas the "case/underscore insensitive" qualifiers lets you have 10 different versions of the same variable name, in the same codebase -- even without using any third party "library".
Besides, the problem of "third party library uses a different style" is easily solved by having a tool like go fmt that enforces a unique single style. End of story.
I can see the point though that grepping, and things like editors which highlight the selected variable would have to take these rules into consideration. It's a valid concern but I feel the benefit of clean unified code is more important.
Whereas referencing the exported identifiers from the library with a different style than they are written with in the library's code sounds more satisfactory to you?
I can see why you are skeptical of it but once you've used it for a while it becomes second nature. And you can always mix if you want to. The thing is that you can choose how you want to do it. And there are extremely few cases where the casing actually makes the identifiers different (keeping it mind that the first character is type sensitive).
Labels (e.g. variable names) coming with style insensitivity is indeed weird, and likely to be far more off-putting for many than significant indentation, though both put together will likely have even more of a negative effect on adoption, in my estimation.
I can imagine benefits to the style insensitivity, but I think those benefits could be had without a style insensitivity, and they come with trade-offs as well when you use style insensitivity to get those benefits (for instance, some typos could be ignored altogether by the parser, but cause the human eye to miss them or cause codebase searches to fail to find all instances of a label when using tools external to the language's implementation itself).
I think some of the benefits of style insensitivity are worthwhile, though, and should be pursued (by other means, preferably). For example, a language feature that allows one to define (with a single line of code, perhaps a pragma declaration) a standard for label formatting could be used to make library functions conform to your project's code style standards would be a much more palatable solution to the problem of alien code looking alien than style insensitivity, in my opinion. I think a (Proposed? In development?) feature of Nim -- syntax "skins" -- might offer exactly that, and it could result in effectively being able to turn off style insensitivity in your projects. If so, I would expect that to become the standard way to handle code style in Nim projects.