I started reading the.NET magazine article about Yukon and this weird remark started me thinking:
"First, Yukon includes XML as a native SQL Server datatype. The capability to store and query XML documents within a relational database will become increasingly important as your migration to XML progresses. For example, you might be required to archive third-party SOAP request and response messages for nonrepudiation or auditing purposes. Support for XPath and XQuery extensions to T-SQL will probably eliminate most organizations' need to invest in dedicated XML data stores. "
XPath in T-SQL? Don't get me wrong, perhaps there is a way that this is useful, but this sounds like a clash of paradigms to me. XPath is a pattern-matching language, which behaves like a functional language. T-SQL on the other hand is a set-based language. To me these two paradigms are not mixable, like it is hard to mix procedural code with XPath code in an XSL sheet, just because they are two different paradigms: functional (XPath) and procedural (the script).
It's already not that good that T-SQL supports all kinds of middle/gui tier mumbo jumbo like string formatting, while constructions etc, but alas, it's there, you don't have to use these statements, however mixing T-SQL with XPath, as a pillar for the suport for the marketing hit 'XML', I think they've gone a bridge too far.