***** D method override mechanisms borked ******

[kris]

Used to be that overriding methods in subclasses had some logic to it. 
Now? Well, who knows:

1) you can override a protected method and make it public. Doh!

2) you can override a public method and make it private ... ok, but get 
this -- the overload is not virtual -- it doesn't "actually" overload at 
all. Very sneaky bug in the making, especially when the base class is 
altered just slightly.

3) to fix #2 let's use the override keyword! Yay! That will ensure we're 
actually overriding the base class method instance! Well, it compiles, 
but does *not* override. Bork Bork Bork.

And so on, ad infinitum.

This was not a problem at some distant point in the past. Now the rules 
are (a) too murky for this simple dude to even comprehend and (b) 
apparently thoroughly broken. The behaviour turns D into a land-mine for 
both the unwary and for the seasoned professional. How to turn people 
away from D in one easy lesson.

Please, please, please revert whatever cleverness was injected there and 
make it work in a clear, precise, /obvious/, and above all, *dependable* 
manner. Heck, make the "override" keyword mandatory if you need to. The 
latter should at least work, or cause a compie-time error.