>From what I understand, your concern is "what if we need to change the direction of something already decided"? For example, initially it was decided and very well accepted private(set), but after a while the idea was revised and it was decided that private:set would be better instead.
In this case, I still believe that the ideal is that this does not change. But we have a options to decide: (1) Do not allow changes of this type, as private(set) was initially well accepted and, unfortunately, nothing can be done. Perhaps, with the exception of code conflicts that might be discovered later. (2) Allow BC if the change is reasonable (in this example, if some sort of code conflict is later discovered). AND: (2.a) Keep the old syntax (private(set)) at least until the official version is released, which will use private:set if possible. (2.b) Keep the old syntax for at least a few releases (eg. patch+3), or a few months (eg. 6 months) if possible. (2.c) Consider BC permanent and users will need to change existing codes immediately. In particular, I believe that option (1) is ideal, or in the last case (2.a). While option (2.c) would be easier to maintain and also acceptable, as users using preview features will be using it at the risk of things like this happening. In general, the proposal is to allow new features to be tested more easily and earlier, as long as they are ready for use and in their final version (or very close to it). Something like a "Release Candidate" version of this new feature. (By top posting, you mean what gmail does by keeping the previous message at the end of the email, right? I'll be more careful, thanks!)
