This is for sets of documents where orderings can be made regardless of the content, so not indexed on a known field but ordered. And not just a single ordering but multiple alternative orderings.
Imagine a box of cards, they're in a particular order first to last. To order them again requires going through each card and placing it in the new order, and the previous order is unavailable until it's reordered destroying the existing one again. The first solution was a separate document of a different type which had lists of orders, each list within the lists had a label or a name, and the ordering was a list of documents in a particular order.
This works but can only work after the documents have been selected and then the ordering applied. That means that all the other features of search or query only happen before the ordering can be applied. That makes bookmarking impossible and so the whole set has to be returned to the client and the client has to manage the paging. This is horrible.
The planned alternative is to have a list of list on each document, the outer list is just the index correlating to the name of the order, the inner list is the order value. The search or query then includes the selected order with result being the values sorted.
Actually implementing this meant creating the list and then using a view to 'join' the documents. Views are always sorted by the key value in the emit(). It took a deal of head scratching before I realised it needed a faceted key, the orderName be so that the vote could be filtered reasonably and the order of the row which comes from the loop creating the row of the selection.
However, bookmarks aren't maintained for views you have to use skip and return the skip value+length to be able to page forward.