Otherwise, the item is injected into the interface, and then the interface has to insert it back into the network somehow. If this second insertion succeeds, the interface's item handler adapter only updates the next tick, causing duplicate items to be shown for a moment.

Implementing this will actually prevent subnetworks from reinjecting back into an interface on the main net through a storage bus. What we should do instead is immediately have the interface's monitor do a rescan after the interface pushes or pulls items into/from the network.

now that i think of it, doesn't the "old" interface have input slots that buffered back?

sounds like an preprogrammed ticklag for improper formed/overloaded networks to me, can't you buffer the item before actually reporting it back (or something like hiding it from the network for the tick until the next update like you described in the OP)

isn't that also related to the (some major versions older) bug that happened with deep storage/black hole units on busses? when they voided excess items or even "unfitting" items when there was no item lock on them?

It looks similar from the outside (an ignored filter), but it really is the fault of the block (interface or DSU) for not properly implementing its filtering. So in this case it's our fault. 😄

yeah i understand, what was grinding my gears here is, if there would be a better solution to this (is simulating transfers still a thing? so pushing would not be done in the first case) ... can imagine other mod writers to all into that pit and the (invalid)blame would fall back to AE in those cases probably

Simulation is not really related to this. Unfortunately, if the inventory does not prevent insertion somehow, then we can't know it doesn't want the items. This is the contract of the item transfer API. Or in this case, of our internal ME network transfer API. :P

Addressed either by an earlier commit or by #5789, at least I can't reproduce it from the PR.