With the recent LINQ CTP, XLinq's feature set is getting close to what we plan to release in "Orcas". The whole point of Community Technology Previews, of course, is to get feedback from potential customers about what they like, what they don't like, and what more they need in a product before the design is frozen. Now is definitely the time to let us know what you think; there is some time, but not a lot of time to try this out and send feedback (The target ship date for Orcas is not public, but since one main point of Orcas it to provide tooling for new Windows Vista and Office 2007 features, you might guess that "months not years" after these ship is the target date).
I'll try to post here a couple of times a week with details on some specific decisions we've made that may be controversial, and to talk about some issues we're still wrestling with. Here's my current TODO list of topics to write about; please let us know what else you might want to see discussed.
Note that one topic which has generated some discussion is not on the list - there definitely will not be XML literals in C# 3.0 the way there is in Visual Basic 9. There is what I consider a very nice compromise, a "paste XML as XLinq functional constructors" feature implemented as a Visual Studio addin. There is a preview in the May CTP, so let us know if you agree.
Finally, I'd appreciate any thoughts you have on a meta-issue: XLinq is aimed more at mainstream developers who need to work with straightforward XML simply yet efficiently, and less at at XML specialists who already know SAX, DOM, XSLT, etc. and tend to focus on the hard problems and corner cases. The problem is that this target audience doesn't read XML-focused blogs or mailing lists, and may not think much about XML at all until they have a project to work on. On the other hand, we get all sorts of input from "Einstein" developers (especially within Microsoft) along the lines of "if you only did X, we could do Y a lot better than we can with DOM or XmlReader/XmlWriter". We worry that accomodating all these (perfectly reasonable) requests could end up making XLinq into another DOM (but with a reasonable naming scheme and native support for C#), not something that ordinary mortals can figure out with a little knowledge of XML basics and a lot of help from Intellisense. Ideally simple things will be simple, and complex things possible by extending the API (via subclassing, the annotation mechanism, and using XmlReader/XmlWriter/XPathNavigator as appropriate), but the more "smarts" we put in the harder it is to reproduce the behanvior in subclasses. Lots of devils lurk in the details here, and your suggestions about how to exorcise them would be very welcome.