I normally set up my inventory by having a drawer controller at the high priority followed by low-priority dump chests.

The problem is that for some reason, the items that should be going to the drawer controller are ending up in the dump chests. Even if the controller is set to the high priority and is the first connected to the inventory connector

Yeah, and if you have no drawer controller. The interface will see the items in the drawers, but will not send them to the drawers, as it thinks they are full.

I have the same problem and could narrow it down further.

When the drawer has less than a full stack, the drawer is chosen according to the priority.
When the drawer has a full stack or more, the items go to lower priority storage, that still has free slots.
If there are no free slots in other storage, then the items are deposited in the drawer correctly.

This is strange, as in prior versions (1.20.1 and earlier) the priority in connected storage was working without problems.

Relevant info: I used the drawers from the Functional Storage mod. The problem may be caused by a specific interaction between the two mods

I have traced the bug to its root cause, the class responsible here is InventoryChangeTracker.

This caches information about the content of an inventory as normal ItemStacks.
To check if a slot is full, the current amount is compared against ItemStack::getMaxStackSize

As ItemStack is a final class, mods can't subclass it, so inventories with larger stack sizes instead implement IItemHandler::getSlotLimit() to return a larger size than ItemStack::MaxStackSize() would.

To fix this bug, information about the slot limit needs to be stored along with the content of the slot.

I created a very quick-and-dirty implementation of that here: https://github.com/456Xander/Toms-Storage.
Priority then works correctly with a mix of drawers and chests again.

@tom5454 if you would like, I can clean up the code and create a PR (or maybe you have a better overview of the code and see a trivial fix)