Why dotnet team prefers abstract classes over interfaces?

[dex3r]

In the issue #36617 there is a discussion between creating an abstract class TimeProvider vs an interface ITimeProvider.

@terrajobst says this:

If the request is to make this design interface based I'll bluntlys state that this is off the table, for the reasons we've stated multiple times (abstract base classes are much easier to evolve than interfaces).

I cannot find any more resources stating that. Why is "abstract base classes much easier to evolve than interfaces"? Where can I read more about that?

[stephentoub]

#36617 (comment)

You can add new virtuals to a base class without concern for the diamond problem that is present for Default Interface Methods (which also aren't supported on older versions of .NET). For the core libraries, that's an issue we take seriously; for more niche interfaces that are less likely to be inherited, we've started to accept some risk there, but as interfaces become more core, we're much less likely to use DIMs.