It is difficult to navigate the Message Index when sort order is reversed for two reasons:
1) The commands NextNew and NextMsg move down the list, regardless of sort order. A convenient behavior option would be for NextNew to move in the direction of newer messages, not just down the screen or increasing mesg number. Also, I'd prefer to have NextMsg go to the next newer message and PrevMsg go to the next older message.
I suppose what I'm suggesting is to separate the direction of the sort from the numbering. re-alpine has fixed number order and re-numbers the messages according to the sort rule. I'm suggesting having a display order rule that switches the direction of the ordering, i.e. increasing or decreasing. I really prefer that message 1 is the oldest message, the newest message gets the next integer, and the Index shows the largest number at the top and number 1 at the bottom. Just *show* the messages in the reverse order, don't renumber them.
I can see this implemented in at least two different ways: (a) a display array represents screen order, top to bottom, which points to the message numbers and has it's own, new option section; (b) NextMsg, PrevMsg, and NextNew get new, optional behaviors wherein they move forward or back wrt. arrival or date values in all sort orders.
Why do I like this idea? Because the reverse sort order keeps the newest messages in view, at the top of the Index, while always showing as much of the rest of the Index as possible. Regular sort order allows new messages to fall off below the bottom of the Index view and, when I go to the end, I see only a few other messages and a bunch of wasted Index space. Another way to implement this request is to add an option to make the index view "follow" the end of the Index when new messages are appended. This achieves the same outcome in the regular sort order.
2) When expanding a thread at the top of the Index view, it expands up beyond the Index view. This is less important than (1) and I think this is consistent with the behavior in regular sort order when the expanded thread is at the bottom of the view. In the reverse sort order case, however, you cannot NEXT or TAB to the newest member of thread due to problem (1). But, I think it would be more convenient to have view of the Index adjusted to include the whole thread whenever a thread is expanded at either the top or bottom edge, regardless of sort order.