Forge has net.minecraftforge.items.ItemHandlerHelper.insertItemStacked(IItemHandler, ItemStack, boolean) to insert items into an inventory without care for the specific slot they land in. It goes through all slots and tries to stack the inserted items, then puts the remainder into the first empty slot. (Which, btw, is exactly what users expect when items are transferred and how item conduits do it, too.)

However, due to the extra empty slot at the beginning of the drawer's inventory this will give wrong results in simulation mode. e.g.: If the drawer has space for 1 item left and you try to insert 2. The first item will be simulation-inserted into the real slot, the second one into the "slot 0". So the simulation succeeds, you remove 2 items from the source inventory and try to insert them into the drawer...which fails, leaving you with 1 item you have no place to put.

Sorry but that's nonsense. The simulate option in IItemHandler MUST be accurate. Too many mods (including mine) depend on it being accurate. This is not some kind of fuzzy logic system here

This was posted like 6 years ago so I really need to reach to remember the context.

A single independent simulated insert will correctly tell you if the item is accepted or not, but it does not necessarily mean it will be in the same slot if you go back and read/extract from that slot.

At issue in this case is the helper is implicitly creating a transaction over a multi-insert operation, assuming that it can do its own bookkeeping to know what's in the inventory as it makes multiple simulate calls without actually committing anything. I don't know what to do about that situation.

We have been discussing this at forge discord right now and we think the best solution is that the basin's item handler only has one slot that can accept items at any time. That way with simulate equal to true ItemHandlerHelper would work fine as it would only be able to put 16 items of any 64 count stack in the item handler (since the others will remain locked if simulate is true).
As soon as an actual item gets inserted into the slot the next slot becomes available (accepts items)

The nature of SD's item handling (An item inserted into ANY slot could potentially be routed to another location) means that a change in any slot invalidates the state of the entire inventory. This also applies to simulation, except that you don't have the benefit of the inventory itself tracking the state for you. If the items had actually been committed as you went along, the empty slot would reject all items.

If you hit this because you're implementing a mod, I'd recommend taking the simulation as more of an advisory and having a contingency plan in place if reality is different, or if it's really problematic, consider treating SD as an exception and work with it through its API.