The idea is that develoers prefer different styles of coding. Some like doThisAction, others prefer do_this_action, others Do_This_Action.

Nim supports all styles. A simple reformatter can be used to transform the code of a project into a normalized form. Such an attempt would be very dangerous in C++.

So the idea is that, say, you'd have hooks in your version control system so that Alice always sees lowercase_with_underscores, Bob always sees camelCaseLikeThis, and Charlie always sees camel_Case_With_Underscores; and then each developer sees a version of the code in which everything is consistent, but it's a different consistent version for each? (And the thing in your actual repository is whatever it is -- it could be w_i_t_h___t_o_o___m_a_n_y___u_n_d_e_r_s_c_o_r_e_s for all anyone need care.)

That's certainly better than having different bits of the code use different identifier styles. But it feels somehow a fragile way to do things. And I worry about encouraging bad habits in teams that don't set things up with such care.

And... can you really make a simple reformatter that will consistently do the right thing? Identifiers may make reference to things whose capitalization shouldn't be canonicalized. HTML. TeX. iPhone. DrMemory.

(Also, though this is a bit of a cheap shot: note that the three identifiers in your first paragraph are not equivalent according to Nim's rules.)

I don't see the advantage in supporting all styles. What you describe sounds like a pretty trivial benefit compared to breaking all of your ordinary text manipulation tools and violating the principle of least surprise.