This isn't a very convincing argument to me. "We fail at source code localization in 4 other ways already" is not a good argument for "let's force a failure in

This isn't a very convincing argument to me. "We fail at source code localization in 4 other ways already" is not a good argument for "let's force a failure in a 5th way, too, even though that's the one place where there's no technical issue with it". To me, using English keywords everywhere is a historical accident, not a design goal. In next-generation systems like Subtext [1], it looks entirely possible to add localization to source code, too. Once you throw out the Lisp way of having one namespace for all symbols (or, OK, like 7 in CL), to be used as functions or values, and go to a system where you want to be able to statically type-check everything, why not fully commit to it and let users give local names to identifiers? Then we won't be limited to legacy C-style naming rules, or have to argue about how many space characters to add to make all their names line up on a high-resolution VT100 emulator, either. [1]: https://en.wikipedia.org/wiki/Subtext_(programming_language) https://en.wikipedia.org/wiki/Subtext_(programming_language)