Generally it's not a feasible strategy to assign (or assume as reader) a single context-independent meaning to a keyword.
That may be overstating it, yes. But I am looking here for a positive statement about what kind of addition is "beyond the pale". For example, in C++, "enum class" uses two existing keywords in a new way, but it is acceptable (although ugly as heck), because the resulting thing is 'like' an enum. OTOH, C++'s use of "static" is unacceptable, because it mixes very distinct ideas (file scope, linkage, and instancing in a class) and the context you have to look at to distinguish them is sometimes far away from the line you are looking at. I haven't really noticed this problem much with D, but I worry about the future, because I see a refusal to introduce new keywords, combined with an eagerness to introduce new language concepts. Surely a compelling enough new language concept, would justify needing to provide a migration tool to help codebases migrate to the new compiler?
Another example is "return" used for monads in eg Haskell - even if it only has one meaning in Haskell, it is too mixed up with a different meaning in other common languages. D's "static if" - which is a killer feature if I ignore the keyword - gives me a similar feeling (though it's much less egregious than "return" in monads). "static" is a terribly non-descriptive name because there are so many senses in which a thing could be "dynamic". What we mean in this case is "compile-time". I think!
