Apesar da sua grande flexibilidade, o mecanismo de envelopes e cartas sofre de algumas limitações, relacionadas com o facto de se ter um objecto estranho no programa.
No entanto, e como se verá depois de ter sido apresentada a realização do protótipo, a maior parte das limitações devem-se à realização do modelo utilizando uma linguagem concreta. Os problemas relativos ao protótipo serão apresentados no capítulo 7.
Os problemas que podem ser encontrados no modelo estão relacionados com o facto de algumas aplicações tentarem aceder ao objecto sem ser pela interface que este apresenta. Tentando fazer a mesma coisa com o envelope que está no lugar do objecto carece de significado.
De forma análoga, o modelo apenas tenta intersectar a interface pública de uma classe. Se, na interface original, alguns dos métodos não forem públicos serão ignorados pelos envelopes. Este facto não é um problema grave porque os métodos não públicos são invocados directamente sobre o objecto, como se fossem código inline, ou seja, a invocação não implica o uso de um envelope.
Comparando o modelo proposto com os smart pointers e com os acessores do OATH, apresentados no capítulo 2, verifica-se que não apresenta nenhum dos problemas daqueles relacionados com a herança múltipla e conversões de tipos. O motivo pelo qual aqueles apresentavam os problemas estava relacionada com a mistura de objectos que existia na aplicação: esta via smart pointers e objectos, num caso, e acessores e objectos, noutro. No caso dos envelopes, a aplicação nunca vê os objectos originais. Só é necessário garantir, e o modelo fá-lo, que os acessos dos envelopes às cartas se processam de forma coerente.