The "good" setup is:
- have items flowing down a belt and put into a chest by an inserter (capacity 1)
- wire the 2nd to last tile of belt to both input & output of an arithmetic combinator
- belt doesn't enable/disable but does send contents, in pulse mode
- inserter isn't taking items from the tile of belt pulsing the signal, but a later piece of belt
- arithmetic combinator configured as Everything + 0 -> Everything so it tallies the historic total of item flow
I can imagine using this functionality for stuff. It's the "good" setup, the baseline. The leftmost in the included blueprint, which is probably easier.
The "weird" setup(s):
- the belt and combinator still wired & set up the same way
- have the inserter grab from the same belt tile that is pulsing the circuit value
But if both lanes are full, the inserter picks 1 item off, the belt still pulses 4 for a full belt even though there are 8 items over both lanes. So in some cases the signal pulse isn't even the count of belt contents, but lane contents.
I can't really see how it's useful to pulsing full belt contents when only one item flows in, but maybe someone else can. The thing that really makes this a bug (to me) is the discrepancy between the output signals when 1 vs 2 lanes are filled with items, and the discrepancy between counts when the inserter is taking from the circuit pulsing belt rather than from subsequent belt after the circuit pulse.
Expectation:
I'd hope that all three circuit networks of the attached blueprint count the green chips at the same rate, and agree with each other & the box contents (to within a constant because belt buffer). However, they don't increment at the same rate.
Identification credit goes to SeiferKatt, clipped from their stream, they also talk through some of it:
https://www.twitch.tv/seiferkatt/clip/T ... -5Rw7CfOyQ
I just reproduced this - both 1.1.80 and 1.1.81 - and built the demonstrating blueprint thing.