Here's the dilemma as I see it: A carefully designed library that introduces a small set of coherent concepts can make good use of powerful syntactic abstracti

Here's the dilemma as I see it: A carefully designed library that introduces a small set of coherent concepts can make good use of powerful syntactic abstractions and result in readable and succinct code. But application code that implements a large number of one-off requirements is far harder to read if you cannot rely on fixed semantics of basic syntactical elements. The usual response to that is to say that we shouldn't restrict the features available to good developers just because bad developers might abuse them. But this argument is flawed. If you read syntax that can be overloaded then you have to account for the possibility that it actually is. It's the possibility that creates the mental burden, not the fact. I think the solution is for languages to provide a basic set of syntactical elements that cannot be overloaded and are sufficient to write all code. Additionally, there should be optional syntactical elements that can be overloaded even to the point of creating DSLs. The important point is, there has to be a local cue that tells you whether or not you have to watch out for redefined semantics.