If everyone is using this tool anyway then style insensitivity will not be a problem, and for those cases where some library uses snake_case instead the code formatter will still be able to format your code completely consistently even if you're using that library. There is no way that gofmt or any other language's code formatter can do that.
This is such an incredibly small inconvenience, I have no idea why the Nim language would choose to make identifiers case/_ insensitive. Basic refactoring tools become unnecessarily more complicated.
Just searching for an identifier is a complex regex instead of what should just be ctrl+f.
"Basic refactoring tools" would just need to replace the case sensitive search with insensitive. Every editor knows how to do that.
If you're talking about the underscore and first letter rules - yes, they're different, and that's why nim includes nimgrep, and support was added for just about every editor under the sun already (Emacs, VSCode, Vim, Sublime, TextMate at the very least). It's still Ctrl+F
https://docs.python.org/2/library/queue.html
Before 2.6, the situation was even worse, with camel-case methods in the threading module:
Nim on the other hand takes a different approach, don't trust anyone else to keep things the way you like it, but rather allow you to use it however you want. This means that if some inexperienced Nim programmer who didn't care to look at the NEP 1 style guide (yes Nim also has a style guide, which says Nim prefers camelCase), but nonetheless wrote an interesting library could still see his library used by others.