Seems like the Arc-philosophy-response would be, let 'em redefine _ if they want to. And that philosophy will probably make me want to murder somebody one day.
Driving a Ferrari is rarely a collaborative endeavor :-)
Keeping `_' safe in fact increases the programmer's freedom. If I knew that by doing something I was going to fk up w/ other people's code and how they expect their code to behave, I would rather not* do it. OTOH, if there are namespaces, etc. then I know that I can enforce whatever coding conventions I want, in the privacy of my personal sandbox.
Programming is not only about communicating w/ computers; it is also about communicating w/ other people, i.e. your coworkers and so on. Nothing that makes it harder can be a Good Thing. (Of course, unless you are the Lone Wolf coding in your cave---but then you are probably using your Own Better Language and don't care about Arc anyway ;-).)
Freedom is an interesting philosophical topic. How can a restriction make you more free? Well if you drink the FSF GPL Richard Stallman branded Kool Aid, you might "get it", but I sure don't.
I don't want the freedom from doing things, I want to the freedom to do things.
That said, strictness and protection and safety of some language features is something some people would like to rely on.
I think operator overloading in C++ was a huge freaking mistake for instance. You can look at two piece of code without going through some contextual learning to find out what the hell "+" was just redefined to do, and I think that's crappy.
Other languages get by some how without operator overloading. And often without a loss of expressiveness.
That said, judicious use, and education about how subsystems in software work is a necessity even in the presence and absence of things people might consider to be abominations, like operator overloading :-)
