There is always a well-known solution to every human problem - neat, plausible, and wrong. — H. L. MenckenIn software design, there often appears to be a situation where you either get a concept exactly right, or it will just be plain wrong and mess up your entire downstream development. (Maybe sometimes there are multiple good ways to solve a problem, instead of just one, but the wrong ones will always outnumber them.)
I think a good example is the difference in lexical scoping in Scheme vs Python. For my tastes, Scheme gets it exactly right, and harvests a lot of benefits from its clean design, whereas Python is just plain wrong, and harvests a lot of pain, everywhere. [In my limited experience.]
How can we avoid making systemic design errors? One way is to stick to what works. If you're designing a new PL, and your lexical scoping is different from Scheme or Haskell, I think you have a lot of explaining to do.
To know what actually works, you need taste. To create new designs without systemic error, you need a lot of midnight oil.
Which brings us back to:
Why do you glorify doing something new and stupid, when doing good things well is what people really should be admiring. — Linus Torvalds