Ultimately, I had to choose something to commit to for a while as there are just not enough hours for me to learn multiple new languages outside of work and with my various other hobbies.
But rest assured that Nim was absolutely a front-runner and I'm happy to update the post to reflect this.
I do too, and that's exactly why you should use Nim. It is, perhaps, the only language in which the variables "camelCase", "camelcase" and "camel_case" are the same (though CamelCase isn't) -- so you don't have to follow braindead Java principles if you don't like them.
And if you really insist, it is quite easy to write a simple program that will unify the styles for you. In practice, it's not a problem.
In this respect, Nim inherits pascal's case insensitivity, and just adds a few minor and arguably useful details (underscores are ignored, case of first letter preserved). It was never a problem for Pascal (or BASIC, or Excel, or NTFS or HFS+) and it's not a problem in Nim.
And being an early Python advocate and evangelist, I feel history is rhyming again .. ."What? You use significant spaces ? That's so stupid, and bound to make everything fail. Yes, some people still dislike significant indentation, but by and large, experience shows that it's not inferior[0] to token block delimiters, and in some ways it is superior.
[0] as long as tabs are a syntax error ....
This is what style insensitivity is meant to fix. In reality, you are able to tell what style a code base uses almost immediately and grep accordingly.
I find this horrifying and think it probably reflects deep philosophical differences between myself and the creators of Nim. Languages shouldn't make assumptions and how to interpret my typos. They should tell me about the typo and suggest a possible fix.
What you say is equivalent to "I want to be able to declare three independent variables called camelCase, camel_case and camelcase", and Nim says "no, you can't do that in the same scope" (which is a little more strict than pascal which says "you can have camel_case distinct from the other two, but those two are equivalent).
Experience shows that case sensitivity is harder to use in general[0]; "Although we resisted changing the Python implementation, our user testing data forced us to make ... Python case insensitive. Over 85% of our users made case errors and many continued to do so even after learning that case was significant." it's just that you're used to it; same with respect to int/int vs true division.
I'm feeling an almost dejavu to the early days of Python, when the standard response (which people still repeat sometimes, though rarely these days) was "what!?!? you mean spaces are significant!?!? that's horrible". But this is equivalent to saying "I want to be able to write code that behaves differently then it looks, such the C code:
if (nuclear_launch_detected)
notify_the_president();
launch_strike(STRIKE_MODE_MUTUALLY_ASSURED_DESTRUCTION);
[0] page 5 of http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.908... - all of it is a fantastic read.
And why are case errors a big deal in case-sensitive languages if they cause "undefined" errors or, better yet, are caught by static analysis?
(To your point about Python, I still think semantic whitespace is insane -- invisible code, as you implied -- and is a major reason I avoid Python when possible.)