“we are improving these … press ok to accept?” YES! At a BARE MINIMUM!!! 
They really need to switch to an opt-in model, and ideally, they need to let new features simmer under feature flags/opt-in switches for a good while, and perhaps leverage some A/B testing as well, long before they actually replace existing functionality with new, untested, half-baked functionality. The approach of just shoving half-baked (and I really do mean HALF-BAKED, so many of the new features since 2.0, including the 2.0 release, have been incomplete, poorly tested, buggy, unstable, poorly designed, etc.) new features onto their entire user base, they need to be first testing before shipping to the world, then when shipped to the world, ALLOW OPT-IN, and maybe only for a B-test group first to see how the new features track, before opening up access to the feature to the entire user base. Then, once opened, it should STILL be under an opt-in switch, and not immediately and overtly replace all the functionality the user base is familiar and comfortable with.
The diff/review functionality, DESPERATELY needed the above approach, and needs a permanent opt-in switch. I’ll leave that switch off forever, I can’t stand this approach to reviewing code changes, and yet since it was made the primary mode for review, I’m stuck with it unless I can force my thouroughly-pre-programmed muscle memory to do CTRL+CLICK. This is NOT the way to design, test, verify, and vet new features.