I first created this issue on the Mekanism GitHub. They have investigated, and believe the issue is on the Storage Drawer end.

There are some significant and unpredictable incompatibilities between Mekanism item manipulators (logistical transporters and logistical sorters), and Storage Drawers. Depending on the setup, Mekanism either doesn't recognize storage drawers as a possible item location, or doesn't recognize all of the slots within a drawer, or works properly. I recognize that the problem could be on either the Mekanism or Storage Drawers (or both!) side of things.

Steps to reproduce:
Start a fresh modded game with only Forge / Mekanism / Storage Drawers loaded.
Place a variety of Storage drawers, including compacting drawers, full drawers, and multi(2/4) drawers.

Try moving items from traditional storage (chest/hopper etc.) into storage drawers using either Mekanism logistical transporters or sorters + logistical transporters. The issue seems to be that Mekanism recognizes (n-1) storage drawer slots, where n is the total slots in that drawer. That means that a regular storage drawer (one full drawer, one item slot) isn't recognized as a valid target inventory, whether it is empty or already contains the item in question. Any of the other drawers that have more than one slot (like the 1x2 or 1x4 or half size 2 and 4 slot drawers) are recognized both as valid empty inventories in which to place something, as well as valid sources for pre-existing items, but the last slot is always ignored, and stays empty or (if already containing an item) untouched. Compacting drawers are a special case. Mekanism recognizes them as a single available empty slot, and will send a new item into an empty compacting drawer (both from logistical transporters and sorters). Thereafter, Mekanism will only recognize the "top" one or two inventories. An item that compacts into a block, but doesn't partition to a smaller 'nugget' will only be recognized in block form (e.g. the Drawer has two "inventories" and Mekanism only sees the first one). An item that compacts into a block, but also has a subform like a nugget will have the top /two/ inventories visible to Mekanism (e.g. the block/ingot, but not the nugget).

These limitations are partially mitigated by throwing Mekanism item logistics into a Storage Drawer controller block instead of directly into the drawers themselves. The controller seems to expose all the drawer slots to either sorters or transporters, and Mekanism will pull items and fill inventories for anything connected to the controller. In this scenario, the only part that isn't working is that Mekanism still uses the (n-1) rule when considering /empty/ inventory space. It will not push new items into a drawer that doesn't have one of its (n-1) slots available. Once an item is loaded into a drawer, though, even into a 'forbidden' slot, Mekanism will push more items into that inventory.

Version (make sure you are on the latest version before reporting):
**Forge: 31.1.18
**Storage Drawers: StorageDrawers-1.15.2-7.0.2
**Mekanism: Mekanism-1.15.2-9.9.15.408

Here is what they said in response:

Finally got a chance to look into this some, and there is unfortunately nothing we can do on our end. I did some minor cleanup for the next alpha to our simulation checks 6880316 but it does not solve this issue. I believe Storage Drawers is improperly implementing their item handler, as I tested with some debug messages, and the information the drawer returned was very conflicting logically.

For a basic oak drawer, their item handler returns that it has two slots. The first one is their virtual slot, and their second is an internal slot.

The first check we make is to check the maximum amount of items allowed in a slot. (The JavaDocs for that method state: The maximum stack size allowed in the slot.)
Storage Drawers, returns MAX_INT for their virtual slot, and from my debugging was returning zero for the internal slot. (Not sure if this is intended or not I don't feel like looking too deeply into their code).

This means due to them returning that only their virtual slot actually allows items into the slot that is the only slot we attempt to act upon. Next, we check to make sure the item is valid for the slot (it is). And then we check how many items are currently in the destination. Because there is no item in the destination, we then simulate inserting into the slot, and if no items could be accepted into the slot we check the next slot.

The issue however is, that because the only slot StorageDrawers claims can fit more than zero items in is the virtual slot, BUT that any insertions into the virtual slot just fail, we are unable to find a valid slot to insert items into.

I think the name should be changed since the issue also occurs with RefinedPipes. I hope SD can issue a fix soon, i got around it with using a hopper to insert into the storage drawer and the mekanism with logistal sorter into the hopper.

Issue is still present in Storage Drawers 8.0.0 for MC 1.16.1

I can confirm with @DStrand1 that this is still occurring for 1.16.1

It's also happening in Valhelsia 2 2.2.6(1.15). Works for some of the drawers in my system, but the sand is refusing to be inserted. I haven't yet tried to break/replace that drawer yet.

I am seeing similar behavior as well in StorageDrawers-1.15.2-7.0.2. I too thought it was a Mekanism issue until I tried using RefinedPipes as an item mover and ran into the same issues.

I can have a chest with several stacks of a resource ready to send to a storage drawer controller, plenty of room in the drawer or compacting drawer and even add additional upgrades and the items will never send. They'll remain in the source chest forever. The "fix" is to break and re-place the offending drawer.

Additionally, these storage drawers and controllers are not on chunk boundaries.

Thanks for the help!