I discovered a case where a fully compressed half belt of items can be entirely blocked, even when the output is entirely clear, due to a fully compressed belt sideloading onto it part way through. This was achieved without any loops and using only one belt type. I believe similar bugs to this have been reported before (viewtopic.php?p=380043#p380043) and categorised as "won't fix" but I believe this is both a different interaction and a major problem as opposed to a minor bug. The reason is it breaks item priority which can destroy builds which require outputs to be clear (think Kovarex setups, or any number of modded recipes which require item recycling).
Short clip demonstrating the bug: https://clips.twitch.tv/PatientTsundere ... ZJ8IceCVoT
The problem here is that the green chips already on the belt form a compressed lane, and the output is clear so the sideloading green chips should never be able to enter the belt. When building an identical build in another part of the world, it gives the expected behaviour with the sideloaded items not entering the belt unless there is a gap (which can be checked using the transport line gaps debug option). Two identical builds behaving differently is a major inconsistency which is quite unfortunate and unwanted.
VoD from the stream where I discover and explore this (with timestamp): https://www.twitch.tv/videos/1988746056?t=01h57m40s (there is a long break where I am AFK from 2:01 to 2:37, where I return and investigate it some more, there might be some useful evidence in there somewhere that can be used to work out what is happening).
[1.1.98] Side loading on belt has priority over items on the belt
Re: [1.1.98] Side loading on belt has priority over items on the belt
Fyi there's also this post with a little different explanation: viewtopic.php?p=439604#p439604
Also known as JanSharp. jan1i3 was/is my old name ;)
Re: [1.1.98] Side loading on belt has priority over items on the belt
That contained a useful explanation @jan1i3 thank you.