Currently, both in practice and in the wiki documentation, the drawer preference for an incoming item to a controller is:

1. Look for any drawers with a void upgrade and contain the same item.
2. Look for any drawers that are locked and contain the same item.
3. Look for any drawers that are unlocked and contain the same item.
4. Look for any drawers that are unlocked and are empty.

If an item can't be placed for a given rule because a drawer is full, it will look to the next rule. If more than one valid destination is found at the highest applicable priority, then the slot nearest the controller (by connection length) will generally be chosen.

Shouldn't void be moved down to the lowest priority among drawers that contain the item, instead of highest?

TLDR: If you simply moved it down (or made it user configurable), it would enable a behavior that's currently impossible: having an item be voided only after overflowing all slots that were intentionally dedicated to it.

Reasoning:

• If you have a drawer with an item and another drawer that voids the item, the first drawer gets starved and never receives any.

• Even if both drawers have void upgrades, the more distant one gets starved and never fills. Excess just gets voided once the nearer one fills.

Both of these configurations, when they exist, strongly suggest that the user intends to have the item appear in both places.

Therefore, starving one of the two places is not the preferred behavior. (And it's unpredictable which will starve, since it's only 'generally' the shortest, and there not by absolute distance but connection length - an understandable implementation consequence, for sure, but not helpful).

Example:
Right now I have, for example, lapis and bone meal appearing in two places - each is present in my drawers for dyes, and then I have more lapis storage at enchanting and more bone meal storage at my farm.
All are handled by a single controller (it's a skyblock game, so this is the most practical option), who receives auto-generated incoming items to be dispersed among my drawers. Similarly, the bonemeal is generated as a side effect of other resource generation and I have entirely too much, so I need to void it.

Ultimately, for a given controller, there is no way (right now) to both void an item AND have it appear in more than one slot - but that's only because order of the rules.

Your argument makes sense, but I can't remember if there was a specific reason that void needed to come first. I probably figured 1 and 2 wouldn't occur in the same bank and they would probably be safe to swap.

Maybe even 3 could move around, because I absolutely do not respect slot index on insert anymore, but in the past it would need to be where it is, or a drawer could empty before the list was refreshed and you'd start getting items in unwanted places.

I've changed the priority order to:
Locked, Locked+Void, Normal, Normal+Void, Empty

But it was actually worse than that. It turns out the drawer stack iterator never respected slot priority on items it could find, and with the death of IInventory, everything goes through that now. That's also fixed.

Woo. 😄 Thanks for considering and acting on this. That priority order makes great sense and should enable the desired configurations I was hoping to be able to do.
Assigning a higher precedence to locking than to voiding (i.e. locked+void > normal) was smart. It means that the current behavior (assigning all incoming items to the voiding drawer despite it appearing elsewhere) is actually still possible too - easily controlled by the user locking or unlocking the voiding drawer. So, anyone who would make use of that configuration can still have it even after the change. 👍