A programming language is syntax and semantics.
Spend some time designing a programming language, implementing a parser and compiler, and working on a virtual machine, and you'll discover that both syntax and semantics influence each other. Even so, you can separate them. Myriad syntax forms can produce the same semantics. There are differences in expressivity, abstraction, and concision, but within the same language, you can support multiple syntactic forms (even with differing semantics) from the same set of low-level semantic primitives.
Even though the most effective way to develop a software project over the long term is to get feedback about the problems that users face in their own work and iterate through potential solutions to find the best approach, users tend to hate this kind of churn in the syntax of their programming languages. Even if the semantics don't change (much or at all), especially at the low levels, rewriting for the sake of rewriting is an expensive exercise.
In the long term, better expressivity, maintainability, abstraction, and correctness may make change worth it, but who practices long-term thinking?
There's a lot of pressure to get things right the first time, even if what's right doesn't stay right for long, because there's even more pressure to stick with what's there because it's there and it's good enough.
Consider this in the context of The Replaceable Batteries of Your Standard Library and Replacing the Standard Library with Distributions. Those posts discussed a language's core library. They could very well describe the core language itself. The difference between a library and a language (given a sufficiently expressive language) is one of convention alone.
That convention is important; it's easier to convince people of library changes than language changes. Of course, people believe it's easier to change a library (or provide an old version or a wrapper for backwards compatibility) than to change the syntax of a programming language.
They may be right.
However, Perl 6 separates the grammar of the language from the rest of the language. This is somewhat new for Perl, but nothing new in the world of programming languages.
Perl 6 also lets you create your own local grammar modifications. The most important attribute of these modifications is lexical scoping. You must declare which modifications you use, and they take effect only in the innermost lexical scope of that declaration.
Perl 6's grammar is a self-hosting grammar. It's written in itself. Combine that with lexical scoping and a Perl 6 specification which includes the self-hosting grammar and puts a version number on it, and you have something special.
You can have multiple Perl 6 grammars co-existing in the same program. You can have components written in Perl 6.0.0, 6.0.1, 6.1.0, and 6.2.0. Yes, that could become a recipe for a maintenance disaster if you don't encapsulate your code well. It can also allow you to refactor your code to take advantage of new features and remove deprecated syntactic features component by component.
In other words, rather than Perl 6 defaulting only to those features which are supremely unlikely to conflict with features existing in the earliest releases of Perl 6 (as is the case with Perl 5), the language can evolve and change without leaving existing programs in the dust.
Add to that the policy that you must declare the specific version of the parser you wish to use -- and if you don't declare a version, you get the most recent version available -- and Perl 6 can avoid some of the backwards compatibility concerns that have influenced Perl 5 development.
