Currently, LibreOffice index entries are arranged in alphabetical order. This is appropriate for all main entries and for most subentries in published books. However it is quite common, in published works, to see index subentries in a non-alphabetical order. For example in a bigraphical entry such as: Churchill, Winston Birth Schooling entry into politics Historian World War 2 post-war politics Art Death For bigraphical events, and others, it makes sense to arrange the subentries in DATE order, rather than strict alphabetical order. In other cases the writer may want to arrange according to some other criterion. SUGGESTION: Allow the subentries of an index entry to be rearranged by the user, if necessary, into an order of his/her own chosing.
But you still want the 1st level entry to be alphabetically sorted, like Cavendish, William Churchill, Winston Walpole,Robert And the second level to be sorted by some other criteria since date is the value of your key. I believe this goes beyond the simple index and requires a true bibliography / form/database / macro solution. => WF You can always make the index editable and sort manually. But of course, this will be gone after updating the index.
My guess is that the user would always want to have the 1st level entries alphabetical, and only apply non-alphabetical sorting to sub-levels.
If a user-defined sorting will be allowed, then this must be protected automatically when the index will be updated. No user action like a new checkbox should be introduced. How new entries will be added? Do we need a sub-sorting or will new entries added after the last existing entry in alphabetical order?
I don't think ordering per date is possible or make sense. However, a flexible solution could be desirable (see also https://ask.libreoffice.org/en/question/196363/change-the-order-of-an-index/). Another primary sorting than alphabetically is requested in bug 131315. And while I can image a solution for this, it's hard to figure a flexible approach for 1st and 2nd keys. Keep in mind that we need a solution that works for other applications too. So I believe it's not possible to solve per standard index. The only way I see is per extension that manages the entries. But let's keep the request open for more input.