You can't know how much it excites me to hear that Microsoft is designing yet another computer language. Why, what a novel idea! It isn't like there were hundreds of new computer languages designed every year. If that were the case, there would be conferences about the subject. Oh, wait: that's how we first heard about this one, at the Lang .NET conference on the Redmond campus.
But it's a declarative language! Ah, yes: that eliminates maybe half of the languages proposed every year. "Declarative" is an awfully broad term, with multiple meanings. Standard ML is considered declarative, and so are its derivatives OCAML and F#.
Prolog and rule-based AI systems are considered declarative. You declare the rules: the logic engine decides how to run them. SQL queries are declarative: you describe the data you want to see, and the query optimizer figures out how to get it out of the database.
Haskell is considered declarative as well as functional, not to mention that it has monads. Don't ask me to explain monads in the context of functional programming: it's not a short answer. The "Summarizing Proust" contest isn't on today, thank you very much.
Back to declarative languages. XAML is a declarative language for the domain of graphics. It was designed as an extension of XML. It's such an expressive language that Charlie Petzold, arguably one of XAMLs most vocal proponents, built himself a alternative to Microsoft's XAMLPad called XAML Cruncher, so that he could "interactively type XAML code and see the object it creates." In Visual Studio 2008, Microsoft included a bidirectional, split-screen XAML designer, so that you can create XAML by dragging and dropping objects and by typing XAML code, with the ability to freely switch back and forth between the two methods. I freely admit to needing these tools; I can almost never write XAML that will display correctly on the first try.
Watching the Connected Systems Division (CSD) at Microsoft over the years, it has been clear that they have been on a code-reduction path. Why? SOAP was invented by Don Box and others to be an XML-based lingua franca for communication among disparate computer applications and systems. The functional deficiencies of SOAP were addressed by the WS-* series of standards, to give it security, authentication, reliability, and so on.
All of those standards made it harder to write conformant client and server code, raising the complexity by orders of magnitude. CSD engaged in a series of efforts to counter this by raising the level of abstraction for programmers developing connected systems. Web Services Enhancements (WSE) for Microsoft .NET cut the amount of code you needed to write drastically, but not enough for mere mortals.
Windows Communication Foundation (WCF) brought the amount of code down by another order of magnitude or so, partly by using attributes in code and by depending on XML-based configuration files. Attributes are of course one approach to making a language more declarative, and configuration files are another.
Looking at WCF in Visual Studio 2008, it seems like the classes and attributes and design tools are fairly mature, but are still built on top of the general-purpose C# language and the .NET Framework. I wouldn't be at all surprised to hear that the CSD architects decided to try starting over from scratch with a new language that would raise the level of abstraction and reduce the amount of code that needed to be written for a connected application by another order of magnitude. But it's not like nobody else has ever tried that: there's a robust research community working on that kind of problem.
I can guess about the process they're going through, but I can't guess what the outcome will be. It's an emergent experiment, and there are a dozen ways it could go. Nevertheless the criteria are kind of obvious:
High level of abstraction? Check.
Regularity of syntax? Check.
Easy to write? Check.
Easy to read and understand? Check.
Suitable for connection to disparate systems over multiple protocols? Check.