global search-replace was/is already easy with nimgrep, which ships with Nim 1 and 2. So the real real reason, even if no one wants to say it aloud (and I in absolutely no way speak for the Nim maintainers, but this is common sense), is to remove a stumbling block for consideration of the language. And, objectively, it simplifies the implementation, so it's easy to state that fact and brush off arguing the de/merits of the old rules for identifier equality.
also yes. i guess my point is that the stumbling block is nedding an unfamiliar tool. what if you use xyz editor? is it trivial to get nimgrep support? to know that you even need it?
So, if you look through many Nim related posts-comments on HN over the years, there was repeated and heated rejection of the language, even for consideration before actually trying it, not because an unfamiliar tool was needed, but because of the case-insensitivity rule itself, i.e. an assessment that itβs just bad/stupid design, too different from what other languages do, etc. and therefore they could not seriously consider spending any time with it.
The real correct reason for this is to facilitate grep/global-search-and-replace/LLM.