Oooph! I'm getting quoted so often, I think should start charging a fee! :)

I can certainly see why the stuff you quoted and especially the notice you mention may make it seem like we're changing stuff around willy-nilly. However, I think I can clarify some of the confusion.

We don't make changes that break 6.c Language Specification tests. Having personally read one of the preview versions of Perl 6 Fundamentals, I'd say it's a safe buy, especially since it's written by someone who's keeping themselves in the loop with Perl 6 development.

The breaking changes the notice you mention refers to are to routines that were not part of the language. They're either internal or Rakudo-only bits that we found some users using. So we published a notice telling people about the changes in those routines, now that they were either removed or standardized to be part of the language, which I think is preferable than simply letting that code break and blaming the users for using something that's not part of the language.

As for the bit you quoted off reddit, wouldn't you say that applies to any large project that got released less than a year and a half ago? New software has bugs and isn't thoroughly optimized. Some stuff is wrong and when it's made right, it may affect your code if you relied on the wrongness.

So on one hand, we could modify non-spec code any way we want and not tell anyone, blaming the users whose code breaks for using those routines. We could tell half-truths to people and say Perl 6 is magical and farts rainbows. Or... we could be realistic and acknowledge that there're still many performance improvements we can make and bugs to fix, and we can spend the time to address the userbase who use untested parts of bleed features.

I prefer the latter option.

Cheers,
ZZ