What can and what cannot be changed in 6.c-errata?

[AlexDaniel]

See rakudo/rakudo#3051 for an example. Basically, sometimes devs want to change the behavior in 6.c-errata (it's much easier to fix things for all language versions at the same time without introducing backcompat), but we don't have any list of reasons that can or cannot be used to justify the change of a released spec. For example, in that ticket it is argued that the behavior in that particular case is inconsistent with the rest of the language, so the test is erroneous. However, in my opinion just because something is inconsistent doesn't mean we can change it in language versions that are already frozen.

[vrurg]

I don't feel entitled yet for deciding what must or must not make it into -errata. But one thing I would consider: does it make sense producing spaghetti-code of version checks for every single reason?

An alternate solution would be to duplicate classes in language-specific core. For rakudo/rakudo#3051 that would mean that rakudo/rakudo#2790 must have added new Real.pm into core.e/. What it means in reality is that the way our CORE loading works now two copies of Real.pm will be kept in memory: one for c and another one for e. Not sure how good is it, but this what we gonna get soon to solve #47, where QuantHash and all its descendants would have to be moved over into core.e/.

Another side effect of the above duplication would be complication of fixing bugs which are common to different language revisions. Because the fix would need to be applied to both e and c. Good if the problematic code is not much changed from one revision to another...

Now, I'm trying to extrapolate the situation from 3 supported revisions to 5, 10... Perhaps, not everything would be that horrible if support for older revisions would be dropped over time and they will be removed from core. But this decisions hasn't been made yet, as to my knowledge.