Why Compile Erlang for the CLR?

Erlang for the CLR? Why do such a crazy thing?

• The .NET ecosystem lacks a concurrent programming language. C#, Visual Basic and so on have limited language support for concurrency (basically providing the equivalent of Java's synchronized.) Erlang would ideally fill this gap.
• Windows programmers expect multi-language interoperation, to be able to readily consume common Windows APIs and frameworks, and to be able to integrate with Windows applications. The CLR is the substrate that enables all of these scenarios. Incidentally, a lot of the .NET and Win32 libraries and frameworks complement the common Erlang libraries. (UI libraries, for example.)
  
• The CLR has a security model for dynamically-loaded code called Code Access Security (CAS.) CAS provides metadata for dynamically-loaded code to declare the permissions it requires, APIs for loading code with specific sets of permissions and for demanding permissions dynamically, and security policy management tools. Erlang's security system is much simpler: permissions are associated with entire Erlang virtual machines ('nodes') which can either be completely trusted, or not trusted at all. Bringing CAS to Erlang would make secure, distributed programming in Erlang first class.
• Erlang occupies an interesting spot: It is dynamic, functional, and concurrent. That is new territory on the CLR.
  
• The CLR runs on servers, the Windows client, and in browsers. That is new territory for Erlang.