Personally, I agree, but the Nim lead dev looked into it and declared it "unreasonably hard to implement with unknown effects for template instantiation"
https://github.com/nim-lang/RFCs/issues/547#issuecomment-1879179448
I wish he had detailed the problems more as I think opt-in to insensitivity at import time with some kind of compile-time error for ambiguity is The Better Answer. { For then Nim would not be taking away ident choice from (many) creators in order to support the ident-pickiness of (many) consumers. It's hard to measure/know/forecast, of course, but I suspect the 2nd "(many)" (the number of such very picky consumers) is low in absolute terms in spite of usually high name-consumer/name-producer ratios. A huge fraction of people just go along with whatever the name-producer did, a small fraction complain loudly, and a
Read the rest
n even smaller fraction would care enough to opt-in to insensitivity if such were available and, say, sometimes caused trouble. There is also a "broader system" aspect of the producer-consumer ratio changing as a prog.lang goes from dark horse/obscure/niche to popular (with a lot more consumers). }
All this said, I would reinforce what others here have said - the property is not actually as onerous in practice as you might imagine. So, it is really worth suppressing knee-jerk reactions to this one feature and giving the language a try, just with `nim c/cpp/js --styleCheck:usages` or whatnot.