Deverá ser implementado um tipo que represente CPF ou CNPJ?

[ircnelson]

Talvez isso pode ser um problema a ser resolvido por quem está utilizando a lib.

Em algumas aplicações não se limita ser só Cpf ou Cnpj, tem casos de Cpf, Cnpj, Rg, Passaporte, Cnh... Tentar encapsular essa problemática na lib, não sei se seria uma boa.

Mas, se for tentar resolver, poderia ter uma estrutura de dados que seja Documento, DocumentoIdentificacao, DocumentoPessoal etc. E dai é feito a boa e velha checagem pela quantidade de caracteres pra tentar construir um Cpf ou Cnpj, armazenar em uma propriedade respectiva e colocar numa propriedade enum qual foi o tipo construido.

public struct Documento
    {
        public TipoDocumento Tipo { get; }

        public Cpf Cpf { get; }
        public Cnpj Cnpj { get; }

        public override string ToString()
        {
            return Tipo switch
            {
                TipoDocumento.Cnpj => Cnpj.ToString(),
                TipoDocumento.Cpf => Cpf.ToString(),
                _ => string.Empty
            };
        }
    }

    public static bool TryParse(string s, out Documento documento) { /*...*/ }

    public static Documento Parse(string s) { /*...*/ }

    public enum TipoDocumento
    {
        Cnpj,
        Cpf
    }

Não me parece elegante... mas vale a discussão :)

[henriqueprj]

Acredito que o cenário que você abordou é muito válido, principalmente em termos de abrangência. No entanto, em nosso cenário de Brasil, vejo que é muito comum o armazenamento e uso do CPF e CNPJ. Então quando pensei, nesta estrutura, foi por ter visto isso repetidas vezes no mercado. Ou o cara aceita CPF, ou CNPJ. Isso não invalida o cenário proposto pelo @ircnelson. É um cenário válido, mais abrangente.

Outra forma de pensar nisso seria usar o conceito de Union Types. Algo do tipo Either<Cpf, Cnpj>.

[ircnelson]

Compreendo.

É, se tratando de design, union types é um bom candidato mesmo. O único problema é que toda vez teria que ficar fazendo pattern matching.