Thank you for the explanation!

@Dave: I think Shafqat put it best. Instead of having a default for making the method virtual like in Java, the developer is left to make the decision in C#. Maybe a default makes sense, but then the question of whether it should be virtual or non-virtual comes up. C# (like C++) methods are non-virtual by default. Why should there be an exception for interface methods in an abstract class?

Therefore, IMO, you are correct to assume this is an oversite in the language implementation.

Even if the IL code needs the method stubbed out for some technical reason, the compiler should hide this fact from the programmer.

While you are correct that you might override the methods and make them abstract, this would be unusual and while it should be allowed, it does not explain the requirement to define it in the abstract class.

At first it is rather strange but then again it might steer people to write basic implementation methods which make sure for example that the conditions on calling the method (argument not null, etc.) are met, and only then call some abstract (virtual) method named the same expect for an “Internal” prefix.

Perhaps more discussion on how aren’t Java’s final methods essentially (user-wise, not necessarily implementation wise) the same as non-virtual C# methods.

Yes those “seal” the method from being overridden in any child class but there’s also the possibility of marking classes or packages as sealed.

In C# I believe you can still provide a “new” method, even if the “previous” implementation has been marked as non-virtual. This is very confusing I think, as you need to have a full reference to the class implementing this method marked as “new” in order to use it.