Eu ainda precisava encontrar uma solução para isto, e o resultado desse estudo vocês podem ver na apresentação abaixo que apresentei para a equipe de front-end da Globo.com.

Update:
Meu amigo Francisco Rodrigues me deu um feedback pedindo pra eu detalhar mais o assunto e é isso que farei agora.

Antes de mais nada, temos que considerar que o padrão conhecido para construção de plugins do jQuery, resolve o problema de maneira formidável somente quando o plugin é bem atômico. Entretanto, quando precisamos dividi-lo, encontramos algumas soluções que trazem consigo uma série de problemas. Vejamos como funciona este formato padrão:

jQuery.fn.invert = function() {
  return this.each(function() {
    var
      $this = $(this),
      inverted = $this.text().split("").reverse().join("");
    $this.text(inverted);
  });
}

$("div#foo").invert();

Como podemos ver, em casos assim, este padrão resolve nosso problema perfeitamente. Entretanto, e quando nosso plugin abrange uma série de outras funcionalidades ou precisa ter uma interface de métodos para ser manipulado por outras partes da sua aplicação?

O melhor caso que conheço para exemplificar este problema, é o jQuery Validation Plugin. Vejam que este plugin na verdade não é um plugin, ele é uma coleção de plugins que podem ou não ter relação um com o outro.

Várias pessoas perceberam este problema e tentaram contorná-lo de várias formas. Dentre as mais utilizadas há a invocação de métodos selecionado por parâmetro. Vejamos:

(function() {
  var methods = {
    myAction: function() { /* ... */ },
    myOtherAction: function() { /* ... */ }
  };

  jQuery.fn.bar = function() {
    var args = $.makeArray(arguments), method = args.shift();
    methods[method].apply(this, args);
  };
})();

$("div#foo").bar("myAction", "myArgument");

Outra opção é fazer o que muitos conhecem como programação orientada a eventos ou, buzz de eventos, onde basicamente, os métodos serão manipuladores de eventos e quando queremos invocá-los, disparamos o gatilho destes eventos. Seria algo assim:

jQuery.fn.bar = function() {
  this
    .bind("bar.myAction", function(args) { /* ... */ })
    .bind("bar.myOtherAction", function(args) { /* ... */ })
};

$("div#foo").trigger("bar.myAction", "myArgument");

Outro problema comum são as informações que temos que compartilhar entre estes métodos do nosso plugin. A forma como desenvolvemos plugins hoje, pode confundir principalmente quem está iniciando, e isso pode originar problemas sérios como variáveis globais ou quase isso. Estes contexto extremamente permissivos podem causar problemas quando que por um agente externo, valores de controle do plugin forem alterados na força bruta.
Essa exposição vai contrário às boas práticas e pode causar problemas inesperados no código.

Por último, já vi casos onde de um método para o outro, a referência do objeto que está sendo manipulado é passado. Isso é feio, muito feio, além de não ser viável quando temos métodos demais pois trará uma grande poluição no código.

Sendo assim, se você precisar dar uma melhora na organização, temos estas opções que mostrei, algumas outras menos populares e ainda, plugins de namespace.

Eu não gosto de plugins de namespace. Internamente, eles fazem um processo muito caro para resolver nomes tipo Java e depois retornar o plugin requisitado. Além do mais, são soluções experimentais que não tiveram adesão. Acredito que o motivo para essa falta de popularidade se deve ao fato de que eles fogem bastante da natureza de como o jQuery atua.

Mas bem, a solução encontrada foi fazer com que o objeto do jQuery recebesse novas funcionalidades durante a execução. Utilizei uma técnica descrita por Douglas Crockford como Object Augmentation. Não é nada de outro mundo. Veja um exemplo simples:

var nome = new String("Diego");
nome.sobrenome = "Fleury";

Então o que eu faço neste pattern, tornar o nome do plugin, seu namespace. E sendo assim, eu retorno o objeto do jQuery com os novos métodos que eu adicionei.

$.fn.MyPlugin = function() {

  this.firstMethod = function() {
    return this.each(function() {
      // Faz algo útil
    });
  };

  return this;

};

// Retorna o objeto do jQuery com a nova função, firstMethod
$("div#foo").MyPlugin();

// Executa o que firstMethod se propõe a fazer e
// retorna o mesmo objeto jQuery modificado
$("div#foo").MyPlugin().firstMethod();

Não sei se perceberam, mas para identificar o namespace, eu convencionei que a primeira letra é maiúscula. Agora todas as partes menores só poderão ser invocadas se anteriormente MyPlugin() for executado. Simples não?

Bom esse pattern ainda tem um problema de performance. Por uma característica da linguagem, quando o código do plugin é carregado, somente a function de MyPlugin é construída pelo interpretador JavaScript. Ou seja, o que está dentro ainda não foi avaliado. O resultado desta construção é referenciado em jQuery.fn.MyPlugin e executado a cada invocação. Entretanto, toda vez que MyPlugin é executado, seu contexto interno será interpretado e avaliado. Neste momento a função firstMethod será construída também. Isso não seria um problema de fosse somente uma função, mas imagine 30 métodos sendo construídos toda vezes que MyPlugin é executado. Pesado não? A solução pra isso é simples. Vamos mover qualquer função para fora de MyPlugin e dentro dele, só faremos referência a algo que já foi construído antes.

(function($) {

  $.fn.MyPlugin = function() {

    this.firstMethod = parts.firstMethod;

    return this;

  };

  var parts = {
    firstMethod: function() {
      return this.each(function() {
        // Faz algo útil
      });
    }
  };

})(jQuery);

Pronto! Até me sinto mais leve. Este pattern ainda nós dá o benefício de fazer opções globais, que podem ser valores genéricos que sere para a maioria dos casos mas se precisar de algo mais específico, pode ser sobrescrito. Vejam na apresentação maiores detalhes de como isto é feito.

No pior dos casos (por favor, evite fazer isso ao máximo), quando você tiver métodos demais, você poderá utilizar a função de extensão do próprio jQuery para não ter de declarar dentro do namespace cada método que quiser referenciar.

Por último, nada impede de você ter namespace dentro de namespace caso seja algo extremamente extenso. Mas se chegar a esse nível, considere a possibilidade de que seu plugin pode ou precisa ser quebrado em mais de um.

As vantagens são notáveis. Dentro em breve mostrarei para vocês o meu plugin de validação e espero que ele sirva como um bom case.

Dúvidas? Sugestões? Erros? Deixe um comentário!

English:
In 2008, when I worked in Compos, there was a demand to build something that simplified form validation on the client-side. In the middle of the benchmark that I ought to know what design I should do, I realized that it would be an extensive plugin and other plugins with the same purpose, chose to divide their parts in plugin format. That is, the plugin became a concept and its precise functions have become plugins, many plugins. The biggest problem of course, was that most of these plugins have names very generics. This caused me concern, which led me to send an email to John Resig about alternatives that might minimize the chances of name conflicts. He replied that the jQuery team was evaluating some possibilities, but nothing had been set.

I still needed to find a solution to it and the results of this study you can see in this presentation which I show to front-end team of Globo.com.