@ssilk: Yeah, I saw that. Mainly why I feel it's cheesy is that logic gates are meant to be the most fundamental, the building block of every logic. Using smart inserters to create logic gates is totally backwards - it already has the equivalent of tons of logic gates in it for it to be able to compare and check inventories, yet you're using it to create the very logic that was already built into it to make a simpler gate? While it can do that, the fact is that it manipulates items to mimic logic gates. Logic gates irl use electricity as input and output, not items
The power switch mod seems to get the idea, though that isn't quite fundamental enough. In real circuitry, the two fundamental kinds of logic to build anything is IMPLIES NOT and AND logic, the former where a constantly on signal is used with input signals to create NOT logic, or multiple inputs to create NOR logic. Everything else is derived from there. And Minecraft redstone way simplifies NOT/NOR logic so you don't even need the constantly on signal, and doesn't have fundamental AND logic, but ah well, everything else it gets right.
@Cerb: I wouldn't rely on that graph as a reliable representation of where you should merge belts. That's correct for your setup at best. As far as we know, anything from simply removing and reattaching the belt, changing smelting speeds, and other unknown factors can greatly affect the optimal merge points, and I've already found that to be true on the first one. Good news though, I found a great way to determine if the merge point is optimal and belt fully compressed - at least on my computer, if belt is fully compressed, the items after the merge point don't even visually move at all if I set game speed to 10. And of course, 10x game speed is a really great way to really see if something stacks or not over a long period of time.
And also, there's no problem with having an ultra fast belt for decompressing the express belt throughput tester. You need to find the optimal merge point for fast and normal belts already with a faster belt, and I never said that you can ignore merge point optimization on having an ultra fast belt decompress the express tester. Having one would be a lot more reliable than using splitters, which is yet another unknown that I need to verify that it doesn't affect compression.
Also, I see that you're using decimal smelting speeds with speed modules. Good idea which I didn't try, and so I took it a step further by using beacons so I can get it even more accurate to 0.1 smelting speed intervals. And so far, I"ve tested normal and fast belts, and am not sure if splitters can keep full compression on express belts, but I'll do that soon.
Results:
Normal belt: 21.5 (highest 0.1 interval)
From your range of 21.4 - 21.6, found it to be like exactly 21.5. It can handle 21.5 without stacking, and 21.6 stacks at an extremely slow rate, even on game speed 10, but it's there alright. So slow that if I were to guess a number between 21.5 and 21.6, I'd say like 21.58 or something, because it takes whole minutes for it to fill that belt.
Fast belt: 36.0 (highest 0.1 interval)
Yep, confirmed. Far as 0.1 intervals go, 36.0 is the exact total smelting speed to reach max throughput on a fast belt. 36.1 starts stacking, faster than 21.6 stacks for normal belts, which is why I'm sure the exact total smelting speeds for them must be finer measurements than 0.1 smelting speed intervals. But luckily, that doesn't really matter, because there is no way to get 0.05 intervals
Getting an exact items/second value will require a finer test - this smelting speed based test is a rough way that just happened to show that items/second throughput is higher than what was listed on wiki.
Express belt: ???
Until I test and verify that splitters keep full compression in that setup, don't know the values.
Edit: Found that splitters don't always keep full compression and it certainly doesn't in your setup, so your express belt setup is not a valid setup to test this. One side of the splitters start stacking, normal due to that left side takes priority behavior, but I can clearly see that there's a tiny gap in compression in the merged express belt every 2 seconds or so. And actually, I found that even shifting over that setup of splitters one tile to the right will screw up compression even more. so that merge point optimization thing even extends to splitter placement apparently. Tricky. See if you can find a position that keeps full compression.
Also, I cleaned up and modified your test world a bit and did some console commands, like always day, instant mining, all tech researched, and some give commands. If you want, you can download it here. I find it a lot more convenient to test on.