In all my production work I have very rarely had
to match on text() nodes, though it is not
entirely unheard of.  I tell my students if they
think they need to match on text(), think again
because usually they don't.  Same with XQuery,
and I cringe when I see XQuery examples of
addressing text() nodes directly when it us
unnecessary (and even just plain wrong).

But to answer your question, the data model has a
single text node for your example, and so when
the match happens once, the current node is the
entire string of Unicode characters.

Note, however, that often text nodes will be
broken up *by the user*, though never by the
processor.  The user can break it up as follows:

... where there are three child nodes of <name>,
two text() nodes and a comment() node.

If you only have text characters between the
start tag and the end tag of the element, the
data model promises you will have only a single text node.

XSLT 2.0
I have a problem (probably my own misuse of XSLT) but I run into cases where

<xsl:template  match="NODE/text()">

</xsl:template>

can match more then once in a row.   I have not debugged this yet to
determine if something more complex is really the culprit (probably is),
and the text nodes matched seem to be whitespace  " \n\t .."
But before I really start digging maybe someone could tell me offhand what
the *expected* behaviour is ?

If I have an element lik
                <ELEM>
  some

Text
Here   </ELEM>

is
<xsl:template  match="NODE/text()">

*supposed* to be called once and only once with the entire text children or
is it possible that it is called multiple times with chunks of data as the
processer sees fit. ?

I know just enough to hurt myself by knowing that in various data models
the CHARACTERS (aka text()) can be arbitrarily chunked but I dont know (or
know where to look) to answer the above definitatively 

Thanks for any suggestions

--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal