JCR 2.0 introduces a more formal notion of "identifiers" that supersedes the use of UUIDs, but also uses them in a couple of new ways, including in paths.

In order to support JCR 2.0 API, we need to add support for these "identifiers". Here are some requirements taken from the JCR 2.0 specification:
1) Every node has an identifier (§3.3)
2) Identifiers are strings whose formats are not defined (§3.3)
3) Identifier of a non-shared node is unique within the a workspace (§3.3)
4) An identifier must be the most stable one available to the implementation. (§3.3)
5) Referenceable nodes have more stringent requirements on identifiers (§3.3.2; also see §3.8)
6) Correspondence is based upon identifiers (§3.3.3)
7) An identifier may be used as a path segment, but such identifier segments can occur only as the first and sole segment in a path. No other segments may follow an identifier segment. (§3.4.1.1)
8) A path containing a single identifier segment, S0, is an absolute path whose current item is the node in the workspace with the identifier S0. (§3.4.2)
9) An identifier segment of a path is represented in the lexical form of that path as '[' + U + ']' (§3.4.3)
10) An identifier-based absolute path consists of a single identifier segment. It's lexical form therefore consists of square brackets delimiting an identifier, for example, "[f81d4fae-7dec-11d0-a765-00a0c91e6bf6]" (§3.4.4.1.2)
11) A relative path may not contain or begin with an identifier segment. (§3.4.4.2)
12) An identifier-based absolute path is normalized into a root-based absolute path that picks out the same node in the workspace as the identifier it replaces. (§3.4.5)
13) When a repository returns a JCR path, it must be normalized, unless the repository is returning the value of a PATH property, in which case the original, possibly non-normalized form of the path is preserved and returned. In all cases, the returned path must be in a standard form. (§3.4.7)
14) Equality for identifier segments is as defined for identifiers in general, that is, by standard Java String equality. (§3.4.8.1)
15) A referenceable node makes its identifier available on the "jcr:uuid" STRING property. (Note that the term "UUID" is used for backward compatibility with JCR 1.0 and does not necessarily imply the use of the UUID syntax, or global uniqueness. (§3.8.1.1)
16) The identifier of a referenceable node must be a referenceable identifier (§3.8.1.1), and is subject to additional constraints:
16a) the jcr:uuid property must be created immediately upon the node becoming referenceable, which may be upon node creation or upon a later mixin addition. Consequently, the value of the jcr:uuid property before the first persist is not guaranteed to be the identifier of the node. (§3.8.3.1).
16b) the identifier is immutable during the lifetime of the node (that is, until the node is deleted through a remove operation). In particular, the identifier is immutable across move and clone operations. The referenceable identifier is not immutable across copy operations. (§3.8.3.2, §10.6.1, §10.7.3, §10.8.1)
16c) these are the minimum requirements for a referenceable identifier, but implementations are free to exceed these requirements. (§3.8.3.3)
17) When a node is requested by identifier and that identifier references a shared set of nodes with more than one member the repository must return one member of that set. How this node is chosen is an implementation issue. In general, a user that interacts with repositories that support shareable nodes must be prepared to deal with different nodes having the same identifier. (§3.9.8)
18) A node can be retrieved by its identifier with "Session.getNodeByIdentifier(String identifier):Node". A node can also be retrieved by using an identifier-based absolute path with a path-based get method. (§5.1.4)
19) The Node.getIdentifier() returns the identifier of a node. (§5.7)
20) WEAKREFERENCE, and REFERENCE properties can only point to a referenceable node and store the String representation of the referenceable identifier. (§5.10.6, §5.10.6.1)
21) Apart from the specified cases in §10.11.8, the validity of an Item must be as stable as the identifiers used in the repository. (§10.11.8)
22) Treatment of identifiers while importing content into the repository are dictated by 4 options: IMPORT_UUID_CREATE_NEW, IMPORT_UUID_COLLISION_REMOVE_EXISTING, IMPORT_UUID_COLLISION_REPLACE_EXISTING, IMPORT_UUID_COLLISION_THROW. The term "UUID" occurs in the names of certain properties, classes, and methods in JCR 1.0. This usage is maintained in JCR 2.0 to preserve compatibility with JCR 1.0. However, in the context of JCR 2.0 these names should be understood to apply to identifiers in general and not just identifiers that use the UUID syntax or that possess global uniqueness. (§11.8.1-11.8.5)