What about less intrusive change as a compromise?
I'm the C# guy and they solve these problems just with warnings.
Each warning has some ID and compiler spits it out with the
description of a problem itself.
Developers than have 4 ways to handle it:
1) ignore it and live with the warning
2) change the code to be correct
3) disable this exact warning type for a whole project
4) disable this exact warning in source file at the place of the
warning itself
I think that similar approach would be helpful here.
Say we have an Andrei's allocator code which he knows that is
correct. But spits out a lot of false positive warnings. So at
the module header he just adds something like:
pragma(disablewarn, 123);
and don't care about it further.
So personally I wouldn't necessarily deprecate current behaviour
with actual codebreak, but just spit out warning about possible
error which can be easily taken care of and still can be pretty
useful to find possible bugs.
Actually that should be major usage for warnings - notify
developer that something is potentially wrong.
More about C# pragmas for warning handling:
https://msdn.microsoft.com/en-us/library/441722ys.aspx
