Finally had a chance to play around with this more and I figure at this point I'm free to conclude my own discussion...

<doc>
A
<X/>
B
<Y/>
C
<Z/>
</doc>

n1.xslt:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="2.0">

    <xsl:output indent="yes" encoding="utf-8" method="text" />
    <xsl:template match="/">
        <xsl:text>></xsl:text>
        <xsl:apply-templates/>
        <xsl:text>&lt;</xsl:text>
    </xsl:template>

    <xsl:template match="/doc[starts-with(normalize-space(),'A')]">
        <xsl:value-of select="normalize-space()" />
    </xsl:template>

    <xsl:template match="text()|@*"></xsl:template>
</xsl:stylesheet>

output:
>A B C<

(why this isn't '>ABC<' is apparent further down)

n2.xslt:
    <xsl:template match="/doc[starts-with(.,'A')]">
        <xsl:value-of select="." />
    </xsl:template>

output:
><

n3.xslt:
    <xsl:template match="/doc">
        <xsl:value-of select="." />
    </xsl:template>

output:
>
A

B

C

<

(so, the interleaving elements are replaced by spaces; that seems odd to me, though I'm sure that the Rec explicitly defines this behavior.)

n4.xslt:
    <xsl:template match="/doc[matches(.,'^A')]">
        <xsl:value-of select="." />
    </xsl:template>

output:
><

(so it seems matches() matches the whole content, and not individual lines of content.)

n5.xslt:
    <xsl:template match="/doc[matches(normalize-space(.),'^A')]">
        <xsl:value-of select="normalize-space(.)" />
    </xsl:template>

output:
>A B C<

finally--

x6.xslt:
    <xsl:template match="/doc/text()[matches(normalize-space(.),'^A')]">
        <xsl:value-of select="normalize-space(.)" />
    </xsl:template>

output:
>A<

So text() returns nodes between elements, whereas self::node() returns the concatenated set of text nodes (with interleaving spaces).

Perhaps I should have known that, and maybe I did at one time, but there aren't that many XSLT or XPath examples lying around the web dealing with mixed content (or in books, for that matter, though I confess I haven't read yours).

Mixed content might become more frequent of an occurrence now that XSLT 2.0 supports regex, and dealing with semi-structured XML generated from other markup formats seems more practical.

You seem to be adopting a very empirical approach to discovering the language specification. I don't think it's a good idea to discover how a language works by trial and error: it's better to read the specs, and/or a good reference book.

This is not how XML is intended to be used:

<doc>
A
<X/>
B
<Y/>
C
<Z/>
</doc>

Given the kind of operations you are doing, a normal design would be

<doc><X>A</X><Y>B</Y><Z>C</Z></doc>

So it's reasonable to investigate the effect of applying constructs to this XML, but you shouldn't expect that these constructs work intuitively.

In n3 you say "the interleaving elements are replaced by spaces", but as far as I can see, the spaces (actually newlines) are already present in your source document. In fact, a lot of the effects you are observing are confused by the fact that you can't easily distinguish spaces added by the XSLT processor from whitespace that's copied over from the source.

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

I have an XSLT 1.0 and XPath book on my desk at work, and use them regularly. And since the source document I'm using is generated, I have limited control over its format.

You're correct about n3, of course, but n1 is still curious-- if I remove <X/> from the document and run n1 again, I see:

>AB C<

and I've verified that there is no space after the A.

I guess now it's time to read the 2.0 Rec.

If you remove <X/> from the source document then the correct result for n1 is >A B C<, whether you are using XSLT 1.0 or XSLT 2.0. Of course, if you also remove the whitespace before and after the <X/> element then the result will be >AB C<

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference