On 1 May 2018 at 08:39, Jon Snader wrote: > > Tim Cross writes: > > [Snip] >> >> Personally, I feel the new version should be the default and we should >> provide an easy way to re-enable the old version for those who wish to >> continue with what they are use to. >> > > We already have this. The problem, as you say, is > > how we communicate this to existing users. >> > > But here's what I don't understand: what, exactly, is so bad about > leaving the old behavior enabled by default. The new behavior is still > available and naive users don't get surprised. What's not to like? > The problem is that if the old behaviour remains as the default, then that is what new users will be introduced to and the improved new functionality won't be seen. If the new behaviour is the default, there will be a small period of adjustment for existing users, but new users will be benefiting from the changes immediately. For many existing users, restoring the old behaviour is just adding a require to their setup, so it isn't a lot to ask. (I believe there will be some power users with lots of custom blocks who may be more impacted, but as I understand it, whether the new or old functionality is enabled by default doesn't really change the situation for them anyway as they will have to take additional steps to migrate their custom block settings). The real issue isn't about changing the default as much as doing whatever is possible to inform existing users of the change and how to restore previous behaviour if desired. In the past, after an org upgrade, I have seen messages in the *Messages* buffer regarding inconsistent, incompatible changes and what action needs to be taken (I think this occurred when changes were made to TODO templates). Maybe something along these lines could also be done - maybe have a message displayed when someone tries to do a '