Saxon

This is certainly a bug, since Q{}#cdata-section is not even a valid QName.

Also (and I would need to check if this is actually implemented), XDM does not allow adjacent text nodes, so adjacent text/cdata nodes in the DOM should be wrapped by a single text node in XDM.

That (e.g. Q{}#cdata-section) is the EQName property value in the debugger of the Saxon.Api.QName value is see. For a plain text node it is "Q{}#text".

Full property list in debugger looks like

-		NodeName	{#cdata-section}	Saxon.Api.QName
		ClarkName	"#cdata-section"	string
		EQName	"Q{}#cdata-section"	string
		LocalName	"#cdata-section"	string
		Prefix	""	string
		Uri	""	string

I get the same output with Saxon HE 10.6 .NET:

-		NodeName	{#cdata-section}	Saxon.Api.QName
		ClarkName	"#cdata-section"	string
		EQName	"Q{}#cdata-section"	string
		LocalName	"#cdata-section"	string
		Prefix	""	string
		Uri	""	string

Not surprising, the SaxonCS code for wrapping the XmlDocument DOM has hardly changed from the code in Saxon/.NET, except for conversion from Java to C#.

This naming convention might have some origin in the W3C DOM: https://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-F68D095 says

The values of nodeName, nodeValue, and attributes vary according to the node type as follows:

Interface	nodeName	nodeValue	attributes

CDATASection	"#cdata-section"	same as CharacterData.data, the content of the CDATA Section	null
Comment	"#comment"	same as CharacterData.data, the content of the comment	null
Document	"#document"	null	null
DocumentFragment	"#document-fragment"	null	null
DocumentType	same as DocumentType.name	null	null
Element	same as Element.tagName	null	NamedNodeMap
Entity	entity name	null	null
EntityReference	name of entity referenced	null	null
Notation	notation name	null	null
ProcessingInstruction	same as ProcessingInstruction.target	same as ProcessingInstruction.data	null
Text	"#text"	same as CharacterData.data, the content of the text node	null