A primeira coisa a falar do novo .Net Framework é uma que entendo como fundamental: é possível rodar versões diferentes do CLR em um mesmo processo. Mas antes de explicar isso, deixa eu explicar outra coisa. Pra quem não lembra, não é todo lançamento do .Net Framework que atualizou o CLR. Na versão 4.0 houve uma nova versão de CLR, e ela é na verdade a quarta versão pública, mas na verdade é a terceira grande versão. A figura abaixo exemplifica isso:

Notem que a versão 1.0, lançada em 2002, teve um CLR, e que a 1.1, que foi um pequeno ajuste e foi lançada em 2003, teve outro CLR. Então aguardamos até 2005 para o lançamento da versão 2.0 do framework, com um novo CLR, desta vez um grande update. As versões seguintes, 3.0, 3.5, e 3.5SP1, lançadas em 2007, 2008 e 2009 não tiveram um CLR, rodavam sobre o CLR da 2.0. E antes que você comente, eu também acho essa nomenclatura de numeração confusa. De qualquer forma, a versão 4.0, lançada agora em 2010, possui um novo CLR. Se o Deus da numeração quiser, a próxima versão do .Net vai ser a 5, e não alguma 4.x (ou 6, né, vai saber…).

O CLR é responsável por rodar a aplicação. Ele contém os principais componentes de infraestrutura, como os que gerenciam a alocação da memória e sua coleta, segurança, tratamento de erro, gerenciamento de threads, etc.

Esse é o motivo que quando você vai no IIS configurar um application pool, deve escolher a versão do CLR:

E não existe opção para versão do .Net Framework. No meu exemplo, há o CLR 2.0, e o CLR 4.0. Não existe, e vocês nunca vão ver, as opção 3.0, ou 3.5, porque não há CLR 3.0 ou 3.5.

E essa caixa de diálogo existe porque antes era impossível rodar duas versões do CLR em uma mesma aplicação. Por exemplo, se você fizesse um add-in para o Outlook com .Net 2.0, 3.0 ou 3.5, que rodam sobre a CLR 2, não seria possível rodar em paralelo outro add-in feito com a CLR 1. O add-in que subisse primeiro iria carregar junto sua CLR, e o seguinte não iria rodar:

O mesmo acontecia com o IIS 6, quando eram configuradas em uma mesma application pool aplicações ASP.Net que trabalhavam com versões diferentes do CLR. Quando uma aplicação 1.0 subia, as 2.0 não subiam. E vice-versa.

Notem que isso não significa que uma aplicação .Net 2.0 não podia referenciar componentes feitos com .Net 1.0. Nesse caso, tudo rodava no CLR 2.0.

O .Net 4 não resolve os conflitos da CLR 1 com a CLR 2, mas ele resolve o conflito dele mesmo e qualquer uma destas CLRs. Agora é possível rodar em um mesmo processo algo feito com a versão 4 e com a versão 2, ou feito com a versão 4 e com a versão 1:

Ainda não é possível rodar as versões 1 e 2 juntas.

De qualquer forma, imagino que aquela caixinha do IIS vai perder sentido em alguns anos. É um grande avanço, e muito bem vindo.