In general, I'm quite impressed with Indigo. I like all sorts of things about it. But I have some doubts...
Indigo presents a programming model that is quite different from that of the CLR. The CLR's programming model is what you might call “classic OOP.” Object's become instantiated with a call to their constructor, and when no longer needed, memory is automatically reclaimed and resources are explicitly reclaimed by the class. Every field has a visibility modifier specifying what other modules can and cannot access that field. There is a Common Type System that promotes interoperability.
These three issues (object lifecycle, visibility, and typing) are all different in Indigo. While there may be additional issues that are also different between the CLR and Indigo, these are the big three. These are very fundamental issues; I think it's fair to say that they represent different programming models.
The great mistake of J2EE was that it presented a different programming model from “plain old Java.” J2EE had needless complexity and that's something that Indigo has clearly avoided (Indigo's greatest strength may be the “A-B-C” programming mantra). Nevertheless, it seems that with Indigo we have one programming model for in-process (CLR) and another model for out-of-process (Indigo). Is this necessary? Is the difference between in-process and out-of-process so fundamental, like the change between single-celled and multi-celled life, that entirely different models must be used?
Or could Indigo have done a better job creating a unified programming model? I'm not saying that the CLR's current model is “right.” In fact, every application faces issues of versioning and external dependencies and these issues, it seems to me, are essentially the same issues as connected systems. It's just that they don't necessarily crop up the very first time the app is run. Perhaps the time has come to evolve the notions embodied by the CLR.
If it develops that “CLR projects” and “Indigo projects” diverge in complexity and approach in the same way that “Java projects” and “J2EE projects” diverged in the late 90s, the .NET programming community could be crippled in the same way that the Java community was.