Why do shift operators undergo integral promotion?

[so]

On Tue, 09 Aug 2011 21:37:18 +0300, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

>> On 8/9/2011 2:46 AM, Don wrote:
>> > From a discussion on D.learn.
>> >
>> > If x and y are different integral types, then in an expression like
>> > x >> y
>> > the integral promotion rules are applied to x and y.
>> > This behaviour is obviously inherited from C, but why did C use such a
>> > counter-intuitive and bug-prone rule?
>> > Why isn't typeof(x >> y) simply typeof(x) ?
>> > What would break if it did?
>> >
>> > You might think the the rule is that typeof( x >> y) is typeof( x +  
>> y),
>> > but it isn't: the arithmetic conversions are NOT applied:
>> > typeof(int >> long) is int, not long, BUT
>> > typeof(short >> int) is int.
>> > And we have this death trap (bug 2809):
>> >
>> > void main()
>> > {
>> > short s = -1;
>> > ushort u = s;
>> > assert( u == s );
>> > assert ( (s >>> 1) == (u >>> 1) ); // FAILS
>> > }
>>
>> That last is why we can't just change the behavior from C.
>
> The question though is whether that is ever _desired_ behavior in a C  
> program.
> If it's always a bug when it happens, then I'd argue that we can and  
> should
> change the behavior. If there's a legitimate reason why could would want  
> the C
> behavior, then changing it in D would cause problems for porting code,  
> but if
> the difference only matters when there's a bug in the C code, then  
> breaking
> compatibility is only an issue for broken code, and changing it would  
> help
> prevent issues in D.
>
> - Jonathan M Davis

Can't we finally get rid of this compatibility issue by separating?
. for the whole file which can be enabled with a flag to compiler "dmd  
-Cmode ...."
. default it is not enforced, if we desire compatibility we could just  
write:

version(Cmode) // or something better instead of version
{
}

What would be the problem other than the trouble of implementing this?
I hate to see the shield of C compatibility against every good  
idea/solution.