One questions that I am getting more frequently is “Will the next release of System.Xml V2.0 support XSLT 2.0?”. The answer is “No”. It's not that we do not love XSLT (see  and  below), in fact it has proven itself to be both a powerful and adaptable language, but a challenger has risen in the form of XQuery. Developers will soon have a choice to make. The XQuery 1.0 and the XSLT 2.0 specs have been produced in tandem and to a large extent both languages are simply different syntax manifestations for the same thing sharing both a common data model and type system. You can think about this in the same way that C# and VB.NET share the same types and Meta data via the CLR. XSLT 2.0, XQuery 1.0 and XPath 2.0 are just the same query language dressed up in different forms. Learning one means that you can easily master the others.
However ultimately we made the decision that the non-XML syntax (or you could say more SQL like syntax) of XQuery was going to attract more developers in the long run, in the same way the developers on the whole find XPath an easier file-path like syntax to write. The next 5 years will tell whether this assertion was correct. This is also why we have shown little interest in XQueryX for that matter since it is, well, like XSLT 2.0 but less useful. (I predict that less that 0.001% of people will ever care about XQueryX which amounts to about 70 developers worldwide) Anyway back to the point at hand. XQuery is a nicer syntax to author by does not replace XSLT yet mainly from its inability to do template style pattern matching, but it will get there eventually. Certainly like VB and C# these languages will live side-by-side; people will tie themselves to their favorite language and go down dying to protect it.
As a point of comparison for the more usable syntax of XQuery, the well know 99 Bottles of Beer program, which currently has 621 variations, can now be incremented to 622 with a new addition under the X category. Here is the XQuery implementation of this.
declare variable $new-line as xs:string
declare function local:bottles($bottles as xs:integer?) as xs:string
if ($bottles = 1) then
fn:concat($bottles cast as xs:string?, " bottles")
declare function local:verse($bottles as xs:integer?) as xs:string
if ($bottles = 1) then fn:concat(
"0 bottles of beer on the wall", $new-line,
"0 bottles of beer!", $new-line,
"Go into town, buy a new round", $new-line,
"Get some more bottles of beer on the wall!", $new-line
local:bottles($bottles), " beer on the wall,", $new-line,
local:bottles($bottles), " of beer!", $new-line,
"Take one down, pass it around;", $new-line,
local:bottles($bottles - 1), " beer on the wall,", $new-line,
local:verse($bottles - 1)
local:verse(/bottles cast as xs:integer?)
Nicer than the XSLT equivalent? I will let you decide that.
There is functionality in XSLT 2.0 that is unique to it such as Grouping and multiple output documents. So when I am asked “Will you support XSLT 2.0” my immediate reply is “What does it [XSLT 2.0] give you that you cannot do today?”
8/10 answers typically say “How I can add these two dates together” or “I would love to be able to use Regex on this string”. If you are using the .NET platform then you can take advantage of projects like EXSLT (also described here) to do things like this today without the need for XSLT 2.0 and XQuery 1.0 will be able handle the type operations.
So do you need XSLT 2.0 and why? Do you see yourself using XQuery over XSLT?
 We love XSLT enough to have integrated a superb XSLT debugger into Visual Studio 2005 which will be available in the Beta 1 release coming soon.
 We recently asked 152 .NET framework customers “Do you use XSLT in your application development“. The spectrum of customers was broad including large enterprises, ISVs and smaller companies. 52 of them replied “Yes” which is an interesting statistic since it shows that XSLT is now fairly pervasive in the software industry.