Where I found out about this problem came from a Mumbo video, https://www.youtube.com/watch?v=yyyhxRztamE&t=320s, and you can see the problem occur at 4:02.

Scenario: I would like to evenly distribute items among a line of containers (e.g. furnaces)

Implementation:

• Place a line of 15 furnaces
• On top of those, place 15 hoppers pointing down into the tops (or sides, makes no difference) of the furnaces.
• On top of those, place a line of 15 hoppers pointing horizontally.
• On top of the first top hopper (we'll call this the NEAR or INPUT end), place a chest
• Immediately to the side of the lower set of hoppers, place 15 solid blocks and a line of redstone wire of the same length.
• Pointing out of the very last top hopper (the FAR end), place a comparator
• On the output of the comparator place a solid block, a torch on the side of that. Then place a repeater such that the input end of the repeater see the torch and the output end drive the aforementioned redstone wire.

When you place items into the chest, they will flow out and down the top row of hoppers. The lower hoppers will remain locked until the last (FAR) top hopper contains an item. When that happens, all of the lower hoppers will unlock for a moment, allowing a single item to flow down into each furnace.

Expected behavior:
At the time that the unlock happens, every top hopper contains one item, so every furnace will receive one (more) item.

Actual behavior:
The 9th hopper from the input end (or the 7th from the far end) does not transfer an item to the lower hopper.

I don't think it's losing any items, and I don't see extra ones falling into the hoppers closer to the far end. So my guess is that at the very instant that the unlock happens, the 9th hopper has pushed an item towards the far end but has not yet received an item from the input end.

This is delay-dependent. When I increase the repeater delay to 2 ticks, the "dead" hopper moves two positions towards the input end. If I increase the delay to 3 ticks, the design breaks, but in any case, the "dead" hopper is another two positions closer to the input. I tried a few different combinations, like replacing the repeater with a sequence of two torches, locking the hoppers from torches on the sides of blocks, etc. These will deterministically affect the position of the hopper that receives no items, but there is always a hopper that receives no items.

In one experiment, I placed comparators followed by pistons facing out of each top hopper. This way, I could see when items entered and exited those hoppers by watching piston extension. As items flow into the top chain of hoppers, the pistons extend in a regular pattern. When the unlock happens, the piston one position down the line from dead hopper (towards the far end) retracts ever so slightly early compared to all the rest.

If I put 60 items into the chest, the far 4 furnaces each contain an extra item. If I put 56 in, every furnace (except the dead one) gets exactly four items. So effectively, at the time of the unlock, it's as though every top hopper contains an item except one, consistent with what I suggested earlier about that hopper having pushed an item out but not yet received a new one.

In my understanding, Minecraft computes redstone events in certain batches depending on the type of object. Observers at one time, comparators at another, repeaters at another. As a result of this, it's possible to do things like create 0-tick pulses by having a repeater and a comparator race. Thus, I would expect that hopper item movement would all get processed in one big batch. Instead, it seems like some hoppers get processed, then some other redstone stuff is processed (like the unlock), and then some more hoppers get processed. I haven't tested it thoroughly, but in the same set up but in different locations, I get exactly the same results every time. For a given delay from the comparator, which furnace gets left out is always the same, and it's the same for me as it was for Mumbo in his video.