Using Guids as IDs in a database table, using these IDs in a xml typed field in another table, and building this xml in C# can lead to a non working sql query.
SQL Server converts uniqueidentifier to its uppercase string representation if the uniqueidentifier field is used inside an XQuery comparison expression.
But if the xml field content is built using C# (using the easy LINQ to XML for example) and you just rely on the default ToString method to insert the Guid in the XML you'll end up with a LOWERCASE string representation of this Guid.
So we have SQL converting by default uniqueidentifier to uppercase, and C# to lowercase.
If you rely on defaults any comparison done between uniqueidentifier in this cutting edge xml/sql technology will fail.

Notes:
The xml type is a new native type available since SQL Server 2005. I use it essentially to simplify the model for 1-N relations by storing ids of the N table in a field of the 1 table instead of creating this dummy relationship table I always hated. This without giving up performance, as long as you setup the new special xml indexes for the xml typed field. See references below for the full documentation.

A uniqueidentifier is a 16 bytes (128 bits) value which is used by the default implementation of User/Membership provider of the ASP.NET framework for all unique IDs.

With the xml data type SQL 2005 introduced "methods" that can be used to efficiently query the xml data and use it as if it was a normal table : exists(..), value(..), ...
A common parameter for these methods is an XQuery string, where XQuery is a SQL Server specific language based on XPath, with at least 2 useful efficients extensions in the sql namespace:
sql:variable(..) which is replaced by the value of an existing variable
sql:column(..) which is replaced by the value of any table row available in the t-sql query


References:
SQL Server xml data type
XML indexes
XML type query methods
XQuery language reference