A funcionalidade proposta Default Interface Methods permitiria uma forma limitada de múltiplas heranças em C#, F# e outras linguagens .NET. Inspirada nos métodos padrões do Java, autores de bibliotecas poderiam adicionar novos métodos para uma interface publicada sem quebrar a compatibilidade retroativa ao incluir uma implementação padrão.
Essa é uma funcionalidade calorosamente contestada com fortes opiniões em ambos os lados do debate. E sobre isso, nada mudou. O que é novo, é a possibilidade de ser uma funcionalidade apenas para o .NET Core.
Ao discutir essa proposta para métodos de interface padrão no F#, Phillip Carter da Microsoft escreveu:
Apenas para anunciar, os métodos de interface padrão fornecem uma maneira suportada em tempo de execução .NET ao issue #243 (em algum nível). No entanto, essa mudança poderia estar disponível apenas no .NET Core, uma vez que é altamente improvável que o CLR desktop será modificado para suportar os recursos subjacentes em tempo de execução. Assim como apenas o C#, o F# poderia ter um recurso que funciona apenas se estivermos usando o CoreCLR.
[...]
Os métodos de interface padrão requerem uma mudança de tempo de execução. Isso significa que também há uma validação para a funcionalidade ser suportada em um tempo de execução específico:
Nenhuma versão já lançada do .NET Framework suporta isso atualmente, e é muito improvável que um dia irá, por causa dos riscos de quebrar aplicações existentes amplamente distribuídas. O .NET Core eventualmente terá esse recurso em seu tempo de execução, mas não estará totalmente resolvido se também existir em algum futuro .NET Framework, mono, ou UWP (Universal Windows Platform). E como @jnm2 mencionou, a não ser que todo executor que suporta o .NET Standard também tenha esse recurso, não poderemos usá-lo no .NET Standard. Esse recurso não está nem nos planos do .NET Standard 2.1.
A pergunta que está em minha mente, numa perspectiva de longo prazo, é o que fazemos além de simplesmente assegurar que não iremos explodir com um artefato como esse. Seria o recurso uma cópia do C#? Provavelmente não. Algum tipo de peculiaridade/typeclasses? Isso exigiria um design apropriado que tomaria tempo. E como este recurso seria racionalizado com coisas existentes como por exemplo o SRTP (Secure Real-time Transport Protocol)? Como devemos pensar nas interfaces de hoje x interfaces de amanhã x funções como interfaces x genéricos regulares x SRTP x {qualquer outra coisa}? Pelo menos, para mim, o mecanismo para implementar algo está chegando, então é bom pensar sobre o que essa coisa é em um nível maior, quais tipos de comportamento poderia ter, e como racionalizá-la com recursos existentes nesse espaço.
Na thread the propostas do C#, Joseph Musser respondeu:
Como um autor de bibliotecas, isso significa que o DIM será sem utilidade na situação hoje envolvendo APIs se uma das bibliotecas de destino forem construídas em .NET Framework ou em uma versão do .NET Standard que poderia rodar no .NET Framework. Incluir um método de interface continuará sendo uma mudança de paradigma.
Ao que Thomas Levesque acrescentou: "E uma vez que essas bibliotecas são as coisas mais importantes para o caso de uso de um recurso, isto poderia fazer quase todo o recurso inútil…"