>>"No matter how Racket evolves, the community is committed to preserving what we have achieved: today's `#lang racket` programs will run in the future

So to put it clearly, the current programs would run, but no new features, fixes and enhancements.

Basically you can't use it for anything production.

>>Every fancy new language you make in Racket has access to every library ever made with Racket.

Libraries, means more number of libraries for the same language. Not same number of libraries for more languages.

In Racket, it's the same thing. Racket #langs are interoperable. Which is why it's untrue to say "no new features, fixes and enhancements". Any improvements to the semantics of the language will be usable from both #lang racket and #lang racket2; any libraries written in #lang racket2 will be usable in #lang racket. This is merely a proposal for an official alternate syntax, which you are entirely free to ignore. It doesn't take anything away from Racket to have this.

Bear in mind that Racket already comes with a plethora of officially supported #langs, many of them with highly non-lispy syntax. The ability to do this is a major part of Racket's unique value proposition in the first place.

At this point, it's not necessarily just an alternate syntax.

Given that, #langs can be interoperable, and are encouraged to be, but not necessarily.

For a simple real-world example of interoperability problems, of the kind we could plausibly encounter between two very similar #langs... Consider that RnRS Scheme wants to use mutable lists, but modern Racket wants to use immutable lists. Code in the two #langs might even look almost identical, and even use the same names and calling conventions, but in practice you have trouble interoperating.

There's also factors like: what syntax is in the documentation everyone reads. If all the manuals people see are in a new syntax, the old syntax effectively becomes a dying language, whether or not it's still implemented.

With priorities and/or work, we can support a high degree of interoperability, as well as keeping the current syntax genuinely supported, but we shouldn't assume we get that for free. Nor should we assume it will happen, unless we make it a top requirement that's tracked and remains a consideration in every change.

C'mon. This is splitting hairs. No one doing anything serious, changes their language syntax for their production code overnight. Just think of what this could possibly mean for those people. They need to retrain their people on the new syntax, new ways of maintaining them and who knows what other regression comes along with it(Test cases, deployment, libraries, performance etc). All of this for 0 gains, when better programming languages committed to maintaining backwards compatibility exist.

I think we should settle for the fact that Racket is more like a toy language for teaching purposes. That is ok, given its use case.