Describe your suggestion

I would like to suggest adding an integer option into the #sel command, allowing users to target a specific selection rather than just all, newest, and oldest. I can halfway grok my way through the code, and part of it would probably be adding another TransformTarget and error handling around line 363 in SelCommand.java. Eg:
INDEX(sels -> new ISelection[]{sels[index]}, "??whatgoeshere??", index);
The part where I lose the trail is in command management and argument parsing.

Settings

n/a

Context

Being able to make multiple selections would be helpful, expanding one selection down, and another up for example. This is similar to the newest and oldest, but provides target selection for more than two selections. Naturally it requires the user mentally keep track of their selections.

Final checklist

• I know how to properly use check boxes
• I have not used any OwO's or UwU's in this issue.

To work around the problem of remembering the order we could instead/additionally add a selector to use the nearest selection box.
Preselecting selections might also be an option, but it adds another command in the chain (bad for the user) and unless we want to go for a "selector to select the selected selections" it might cause some argument parsing complexity or even ambiguity as well (bad for the one writing it and for people trying to understand what's going on in SelCommand).

Anyways, some way of transforming the middle selections is definitely a good idea.

Also, is it possible to collapse arguments? eg: default to all if the user does not include enough arguments? Using multiple selections is more advanced behavior than the average user (that I've encountered) barely manages basic selections.
Rather than requiring #sel a shift up 1 it would be nice if the default behavior was to also support #sel shift up 1 and assume that each argument shifted -1 if a valid target selector is not found.

I know, scope creep, it's in the same area though, and overally IMO would simplify 99% of the average player's usage. In fact I only recently realized you could use n or o as alternate targets, so every single command had an obligatory a added in....just to get the command to work.

it might cause some argument parsing complexity or even ambiguity

that's basically this concern. Ambiguity seems not to happen because the directions don't have short forms (so "n" is "newest" and never "north"), so there's just the increase in parsing complexity left. (Which is obviously possible, just look at how many ways you can use #waypoint save).