Thermal Dynamics version: 2.3.6.13
Storage Drawers version: 1.12.1-5.3.3

Unsure if this is a thermal dynamics issue, or a storage drawers one.

If I place a row of 1x2 storage drawers with itemducts along the line, and a chest at the end, and a set of items to go into them, items being piped through the ducts will skip non-full drawers with the same item already in it and go to the next drawer or the end (if the next one has something else in it).

1x1 drawers, caches, chests etc all seem to work fine. If I pre-set and lock every drawer to a different material type, if it skips, it will go to the end of the line to the final chest.

Her'es a quick video of it happening: http://webmshare.com/play/ZjjGK

(crossposted to the cofh issues list - https://github.com/CoFH/Feedback/issues/656)

Really strange how it "changes its mind". And it's not like there's a controller that does periodic network rebuilding that could go stale.

Will need to try reproducing this on my end.

I've just observed the same thing happening with a controller. For example, a snowball came down the duct from the mob farm and went into the controller. The snowball immediately after it didn't, it carried on to the storage crate at the end of the line.
I also tried re-connecting the duct behind the drawer itself. A rotten flesh bypassed the controller and drawer adjacent to the controller (where one of the 4 items is rotten flesh) and went to the end of the line. The drawer wasn't full.

It was only a quick test, but adding a basic filter set to blacklist+overfill seems to be the answer. Everything went into the controller.

I'd blame Thermal Dynamics for this one. It reminds me of the way an itemduct that is sending non-stackable items to a full, locked, void drawer will wait for each item to arrive before sending the next one - as if it only thinks the drawer will accept a single stack.

Try setting the duct to allow overfilling

I've had this happen with Mekanism's pipes (Logistical Transporters) too. I'd opened an issue with them already: mekanism/Mekanism#4896

The issue as far as I can tell ( @jaquadro please let me know if I'm wrong) is that storage drawers shows 1 slot open for each item to other mods. So when they send an item they know that it is going to be filled, and route the next stack of items to the next open slot until the 1st stack gets to it's destination.

To work around this limitation, use either item transport that is instant such as AE or RS, set the ducts moving items to overfill or use a dumb pipe such as buildcraft.

I personally like using the ESD from Actually Additions to move stuff from a buffer chest into my controller, also the buffer from IC2 with the export upgrade.

Either way neither mod is doing anything wrong. They will just need to figure out how to work together is all.

Is there a way to tell another mod that you have 64 open slots per item but only one for extraction?

The IItemHandler interface that was introduced in Forge exposes enough information to mods to tell them that a slot is "deep" and can hold more than a stack. Not all mods account for that and just assume slots are capped at 64.

Trying to expose additional, virtual slots is treading back in 1.7.10 territory. Assuming you can get an implementation without other hidden problems, it's bad for efficiency because mods are going to walk the entire slot list.

At least your items went into a drawer, I have 2x2 drawers pre-set and the items are just flowing right past. Locking and the input side shouldn't matter, right?

I'm currently seeing it with 32 stack and compacting drawers en masse in Stoneblock. Route is chest->sig servo->item duct->bag block->controller->chest... about 90% of the bags make it in, about 50% of the "random loot" like arrows, rotten flesh, etc. Tried locked and unlocked, unlocked it doesn't even attempt to fill most of the chests, occasionally will fill a compacting though. Really weird. Tried changing output to single (1) item, that has no effect, tried better ducts, etc. Finally stumbled into this thread, tried adding a sig filter to the output to the controller and set it to allow overflow and instantly it behaved normally as expected.