This looks like an enjoyable source for weird bugs: Write to functions with similar names (e.g., to_me() and tome()) and be surprised when nim doesn't distinguish between these two.
It's meant to prevent them: in Python applications it's not uncommon to see bugs introduced by an incorrect completion, e.g. updatePlayerstatus / updatePlayerStatus / update_player_status
With case/underscore insensitivity you know in advance that there can be only one "updateplayerstatus" in your codebase and write it according to your style, e.g. always update_player_status
OTOH, if your hypothetical is that programmer X writes `to_me()` while a different programmer Y writes `tome()`, and the two functions just happen to be identical in all parameter types... well, that can already happen anyway where two programmers each independently write a function with the same name.
Nim has a simple, clear specification of how identifiers will be compared: http://nim-lang.org/docs/strutils.html#normalize,string
There's no secret magic happening.
Though, looking at the code for "normalize" it appears to only support ASCII. That's even worse since now "lowercase" doesn't even apply uniformly if your identifiers have non-ASCII characters in them[0].
Doing a general normalization (as in Unicode) would probably also be bad, but for different reasons: You probably don't want the validity of programs to depend on the current locale of the machine you're compiling on. (See e.g. the "Turkish I" problem.)
In short: Case-insensitive identifiers[1] are a terrible, terrible idea.
[0] Not generally a good idea, but it happens and there are legitimate cases for it.
[1] Or, rather, "doing anything non-trivial to identifiers before lookup", I suppose.