O trabalho é, como já foi afirmado, essencialmente independente da linguagem de programação em que funciona. Apenas se exige a noção de objecto que apresenta uma interface conhecida, embora no modelo proposto se tenha restringido a linguagem a utilizar por motivos de simplicidade.
Existe um conjunto de restrições não directamente impostas pelo modelo proposto, mas sim pela forma de o realizar e pela falta de suporte da linguagem para conceitos do modelo e vice-versa. A realização em C++ apresenta muitos desafios neste sentido.
É possível suportar a execução correcta de aplicações na presença de herança múltipla, virtual ou não, e utilizando formas de polimorfismo, tais como conversão de ponteiros. A herança tem, contudo, que ser declarada public.
O suporte a métodos virtuais faz-se sem problemas, i.e., todo o mecanismo de selecção de métodos a invocar funciona como se os envelopes não existissem. Os envelopes ignoram os mecanismos de selecção de métodos da linguagem ao invocar as cartas. Quer isto dizer que se for invocado, num dado nível da hierarquia, um método X, o método X, da carta, no nível correspondente na sua hierarquia será invocado, tal como foi explicado no capítulo 6.
As declarações friend não são suportadas. A utilização deste mecanismo pode trazer problemas, pois, embora os métodos continuem a ser correctamente declarados, na carta, a sua utilização vai ser incorrecta, pois vão referir-se a instâncias de envelopes, que não os prevêem.
É impossível a chamada de métodos que não sejam públicos entre classes friend (pela mesma razão que apenas a interface pública de uma carta aparece no envelope correspondente). A razão deve-se ao facto de as declarações corresponderem a classes que não são o que se espera delas. Nomeadamente, a classe que declara friend fá-lo em relação a outra classe de cartas, que depois se transforma numa de envelopes, fazendo a declaração perder o significado.
As restrições face a friend devem-se ao facto de o modelo não prever a violação de encapsulamento permitida por este mecanismo, assim como também não permite a violação de encapsulamento que ocorre quando se fazem acessos directos às variáveis de instâncias de fora do código da classe, sem ser através da interface exportada por ela.
Uma classe não pode, de um modo geral, possuir uma declaração de método que difira de outra em alguns dos tipos básicos. Esta restrição deve-se à utilização de CIDL e aos problemas de emparelhamento dos tipos nas duas linguagens tal como foi descrito no capítulo 6.
A passagem de ponteiros em chamadas remotas é ambígua, pois não é possível determinar a direcção do fluxo de informação a partir do programa em C++. O gerador de descrições de interface considera o caso mais abrangente: inout (passagem e retorno de dados).
As restrições apresentadas não são intrínsecas do modelo dos envelopes e cartas, devendo-se a ideossincrasias de utilização que a linguagem permite, tais como a violação de encapsulamento, ou a problemas específicos dos sistemas utilizados para realizar parte da funcionalidade, e.g. passagem de ponteiros em chamadas remotas, no módulo de distribuição. A utilização de outra linguagem que não o C++ não poria estas restrições, podendo dar origem a outras.