Hi, Thinking about this more generally, it would definitely be useful to be able to use a more efficient underlying storage for unorderable nodes. However, there still are hard use cases that require us to support orderable nodes as indicated by the type of the parent node. Thus the implementation basically has two options:
1) Use a single data structure for all nodes, like Jackrabbit currently does. This simplifies the implementation but prevents us from enjoying the performance and scalability benefits of unorderable nodes. 2) Use two data structures, one for orderable and another for unorderable nodes. This is more complex (not least because it links node types to the underlying storage model), but is probably required if we want to efficiently support up to millions of child nodes per a single parent. It might also be possible to have the underlying storage model unorderable, and just include extra ordering metadata at a higher layer where also node types are handled. Option 2b, if you like, with probably fairly significant overhead when iterating over nodes (the implementation would probably need to pre-fetch all child nodes in advance to access their ordering metadata). If we do have native support for unorderable nodes, then I wouldn't promise any particular ordering (alphabetic, insertion order, etc.) but rather leave it undefined like in Java's Map interface. The underlying implementation is then free to use whatever ordering it thinks is best. PS. Note that ordering affects not just node traversal, but also the document ordering used in search results. Though in practice we already now disable document ordering of search results by default. BR, Jukka Zitting
