I'm glad that this process does happen (if slowly) in mainstream language design. IMH (and casual) opinion, up through the 80s mainstream programming languages were super ad hoc, but (again, IMHO) from the late 90s formalisms from computer science started to filter into the mainstream. I think this is in part because of the crisis of crappy code and a flood of new developers (before computers were so important, code quality was often not that important) so there was more impetus for "steering away from the bad path".
So for example CLU seemed like a purely academic (and restrictive) project to me back in the 80s, but ultimately spurred a lot of currently mainstream concepts like iterators and strong type systems. It just took 30 years (as did Liskov's well-deserved Turing). Lisp was scorned for its GC, anonymous lambda functions, dynamic type system, huge standard library and many other things, many of which are now table stakes today, 50 years later.
By the way, again IMHO, we lose something when language evolution increases guard rails. The Lisp environments of the 70s and 80s allowed lots of people to manufacture a rope and then hang themselves. But for others they were enormously powerful (e.g. I wrote the base of Cyc, a "blank sheet" reimplementation, in just a few weeks). The Smalltalk environment was like that too: infinitely malleable, designed for people who wanted to explore, and powerful enough to easily kill your machine. Nowadays languages with great expressiveness (e.g. C++, especially if you act as if its long ago "parent", C, doesn't exist) draw complaints that it's "too complicated" and "too hard".
In the 80s, we expected to actually code most of a system ourselves. (even in the mid-90s, I personally recall a startup where we had less than a handful of dependencies on the day we sold)
Nowadays, I gather[0] large numbers of people largely develop by plumbing together a bunch of dependencies.
When it's mostly your own code, guard rails may be redundant. When it's mostly Someone Else's Code, guard rails become effective, if not required.
When it's mostly your own code, there's a lot of crunch code[1] relative to parsley code and glue code, and well-meant guard rails may pose obstructions. When it's mostly Someone Else's Code, there's a lot of glue and parsley code relative to crunch, and guard rails provide a handy place to hang all the plumbing.
[0] if HN can be believed
[1] for definitions see https://news.ycombinator.com/item?id=32498382 . I am confident gumby (along with most —if not all— of this thread) will recognize the latinate names "glue code", "parsley code", and "crunch code" go by, when they're at home.
(Note also that 50 years later, we finally have the hardware to use languages like CPL or ALGOL 68 as they were originally envisioned. Thanks, EEs!)