Currently the internal string representation of a path consists of extended path segments which are tab (\t) delimited.
since JCR2.0, JCR input names can also be specified in an expanded form (see JCR 2.0, 220.127.116.11).
i think it would make sense to use the expanded form also for internal string representation of paths, which is defined by the spec, is more natural and more readable
of course, the PathFactory needs to be backward compatible, since the path property values are persisted in the current toString() representation.
if this is too much of a change, or if there are any valid reasons why the tab-delimited form is needed, we should at least add a new method to Path:
that returns the expanded form representation of the path.