There are some significant and unpredictable incompatibilities between Mekanism item manipulators (logistical transporters and logistical sorters), and the Storage Drawer mod. 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:

1. Start a fresh modded game with only Forge / Mekanism / Storage Drawers loaded.
2. Place a variety of Storage drawers, including compacting drawers, full drawers, and multi(2/4) drawers.
3. Try moving items from traditional storage (chest/hopper etc.) into storage drawers using either 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
**Mekanism: Mekanism-1.15.2-9.9.15.407
**Other relevant version: StorageDrawers-1.15.2-7.0.2

This, except if storage drawers is connected to a logistical sorter once, then it has issues inputting into anything else as well

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.

Thanks for looking into it. I have submitted this as a parallel issue on the Storage Drawers GitHub.