Alguém sabe se é possível definir o equivalente a um "carregador de classe personalizado java" no .NET?

Para dar um pouco de fundo:

Eu estou no processo de desenvolver uma nova linguagem de programação que tem como alvo o CLR, chamado "Liberty". Uma das características da linguagem é sua capacidade de definir "construtores de tipo", que são métodos executados pelo compilador em tempo de compilação e geram tipos como saída. Eles são uma espécie de generalização de genéricos (a linguagem tem genéricos normais) e permitem que um código como esse seja escrito (na sintaxe "Liberty"):

var t as tuple<i as int, j as int, k as int>;
t.i = 2;
t.j = 4;
t.k = 5;

Onde "tuple" é definido da seguinte forma:

public type tuple(params variables as VariableDeclaration[]) as TypeDeclaration
{
   //...
}

Neste exemplo em particular, o construtor de tipotuple fornece algo semelhante aos tipos anônimos em VB e C #.

No entanto, ao contrário dos tipos anônimos, as "tuplas" têm nomes e podem ser usadas dentro de assinaturas de métodos públicos.

Isso significa que eu preciso de um caminho para o tipo que eventualmente acaba sendo emitido pelo compilador para ser compartilhável em vários assemblies. Por exemplo, eu quero

tuple<x as int> definido na Montagem A para acabar sendo o mesmo tipotuple<x as int> definido na Assembléia B.

O problema com isso, é claro, é que o Assembly A e o Assembly B serão compilados em momentos diferentes, o que significa que ambos acabarão emitindo suas próprias versões incompatíveis do tipo de tupla.

Eu olhei para usar algum tipo de "tipo de apagamento" para fazer isso, de modo que eu teria uma biblioteca compartilhada com um monte de tipos como este (esta é a sintaxe "Liberty"):

class tuple<T>
{
    public Field1 as T;
}

class tuple<T, R>
{
    public Field2 as T;
    public Field2 as R;
}

e apenas redirecionar o acesso dos campos i, j e k paraField1, Field2eField3.

No entanto, isso não é realmente uma opção viável. Isso significaria que em tempo de compilaçãotuple<x as int> etuple<y as int> acabariam sendo tipos diferentes, enquanto no tempo de execução eles seriam tratados como o mesmo tipo. Isso causaria muitos problemas para coisas como igualdade e identidade de tipo. Isso é muito vazado de uma abstração para o meu gosto.

Outras opções possíveis seriam usar "objetos de bolsa de estado". No entanto, o uso de uma bolsa de estado derrotaria todo o propósito de ter suporte para "construtores de tipos" na linguagem. A ideia é habilitar "extensões de linguagem personalizadas" para gerar novos tipos em tempo de compilação com o qual o compilador pode fazer a verificação de tipo estático.

Em Java, isso pode ser feito usando carregadores de classes customizados. Basicamente, o código que usa tipos de tupla pode ser emitido sem realmente definir o tipo no disco. Um "carregador de classes" personalizado poderia então ser definido para gerar dinamicamente o tipo de tupla no tempo de execução. Isso permitiria a verificação de tipo estático dentro do compilador e unificaria os tipos de tupla nos limites de compilação.

Infelizmente, no entanto, o CLR não fornece suporte para carregamento de classe personalizado. Todo o carregamento no CLR é feito no nível da montagem. Seria possível definir uma montagem separada para cada "tipo construído", mas isso levaria muito rapidamente a problemas de desempenho (ter muitos conjuntos com apenas um tipo usaria muitos recursos).

Então, o que eu quero saber é:

É possível simular algo como Java Class Loaders no .net, onde eu posso emitir uma referência a um tipo inexistente e, em seguida, gerar dinamicamente uma referência a esse tipo em tempo de execução antes de executar o código que precisa usá-lo?

NOTA:

* Eu na verdade já sei a resposta para a pergunta, que eu forneço como uma resposta abaixo. No entanto, eu levei cerca de 3 dias de pesquisa, e um pouco de hacking IL para chegar a uma solução. Eu imaginei que seria uma boa idéia documentá-lo aqui caso alguém tenha se deparado com o mesmo problema. *