A particular node within a same-name sibling group can be addressed by embedding an array-like notation within the path. For example the path /a/b[2]/c[3] specifies the third child node called c of the second child node called b of the node a below the root.
The indexing of same-name siblings begins at 1, not 0. This practice stems from the need to allow XPath-based queries on the repository (see 6.6 Searching Repository Content).
However, as opposed to the semantics of XPath, a name in a content repository path that does not explicitly specify an index implies an index of 1. For example, /a/b/c is equivalent to /a[1]/b[1]/c[1].
The indexing is based on the order in which child nodes are returned in the iterator acquired through Node.getNodes().
Same-name siblings are indexed by their position relative to each other in this larger ordered set. For example, the order of child nodes returned by a getNodes on some parent might be:
[A, B, C, A, D]
In this case, A[1] refers the first node in the list and A[2] refers to the fourth node in the list.
Note that regardless of whether orderable child nodes are supported in general (see 4.4 Orderable Child Nodes), the relative ordering of a set of same name sibling nodes must be persistent; it cannot change arbitrarily between read method calls or between sessions. This requirement stems from the fact that the path of a node must not change arbitrarily, and in the case of a same-name sibling, its position relative to its co-named siblings defines part of its path.