Qual é o argumento contra a declaração de membros de acesso protegido em interfaces? Isso, por exemplo, é inválido:

public interface IOrange
{
    public OrangePeel Peel { get; }
    protected OrangePips Seeds { get; }
}

Neste exemplo, a interfaceIOrange garantiria que os implementadoresfinalmente fornecer umOrangePips instância para seus herdeiros. Se o implementador quisesse, ele poderia expandir o escopo para o máximopublic:

public class NavelOrange : IOrange
{
    public OrangePeel Peel { get { return new OrangePeel(); } }
    protected OrangePips Seeds { get { return null; } }
}

public class ValenciaOrange : IOrange
{
    public OrangePeel Peel { get { return new OrangePeel(); } }
    public OrangePips Seeds { get { return new OrangePips(6); } }
}

A intenção deprotected membros em interfaces é fornecer um contrato de suporte paraherdeiros (subclasses), por exemplo:

public class SpecialNavelOrange : NavelOrange
{
    ...
    // Having a seed value is useful to me.
    OrangePips seeds = this.Seeds; 
    ...
}

(É certo que isso não funcionaria parastructs)

Eu não consigo ver muitos argumentos paraprivate ouinternal modificadores em interfaces, mas suportando ambospublic eprotected modificadores parece perfeitamente razoável.

Vou tentar explicar a utilidade deprotected membros eminterfaces separando-os deinterfaces inteiramente:

Vamos imaginar uma nova palavra-chave em C #,support, para impor contratos de herdeiros, para que declaremos o seguinte:

public support IOrangeSupport
{
    OrangePips Seeds { get; }
}

Isso nos permite contratar classes para fornecer membros protegidos aos seus herdeiros:

public class NavelOrange : IOrange, IOrangeSupport
{
    public OrangePeel Peel { get { return new OrangePeel(); } }
    protected OrangePips Seeds { get { return null; } }
}

Isso não é particularmente útil, porque as classes já implicariam esse contrato, fornecendo oprotected membros em primeiro lugar.

Mas também poderíamos fazer isso:

public interface IOrange : IOrangeSupport
{
   ...
}

Aplicando assimIOrangeSupport para todas as classes que implementamIOrange e exigindo que eles forneçam particularprotected membros - o que não é algo que possamos fazer atualmente.