cgminer doesn't filter out anything.
It does however (as I have said) use serial over USB, not direct USB.
So the underlying OS code resolves the issue of writing data to the Icarus at the same time the Icarus may be replying.
(and I'd also expect the OS code to be WAY better designed at handling that)
This obviously has yet to cause an error for me (hardware errors=0)
MPBM is no different regarding that, using PySerial to access the board.
Also the up and downstreams of a serial port are completely independent, reading while writing should not be an issue.
If there was a nonce coming back during the picosecond that it starts a new work (writing over the old running work) it would of course be lost.
However that would be something like only a few in 4 billion (2^32) chance of that happening.
cgminer aborts the work at a point before it completes since it doesn't know when the work will complete.
So when cgminer reaches 4 billion shares - yep you may have lost a few
i.e. cgminer may lose roughly a few shares roughly every 2,500 blocks ...
That's not entirely true. The job upload packet is 64 bytes, which is 640 bits on the serial link at 115200 baud, so that's 5.56ms.
During that time, the internal shift register of the Icarus contains invalid data, and thus there's a timeframe of 5.56ms during which the Icarus works on a garbage job, and keeps resetting the nonce over and over again. This alone causes at minimum 0.05% invalids, a bit more if you cancel work rather early.
The maximum nonce value (ignoring the MSB) that an invalid nonce caused by this could have is probably 0x0000406e, which would match the pattern that was reported above if the endianness was reversed and the MSB was ignored.
Edit: also - no it increments the nonce in the normal direction - i.e. an early nonce returned means a low nonce value & 0x7fffffff
MPBM shows the nonces in getwork notation, so that might be byteswapped compared to what the device is actually doing.
Do all those invalids reported by MPBM match the pattern XX[0-4]X00[08]0?
It could also be possible that MPBM is associating nonces received with the wrong job if they are close to a job switch, because there is no hardware feedback about a job switch in the current protocol. But I can't really explain that specific nonce pattern that way.
I'll have a closer look at that when reimplementing the Icarus module for MPBM v0.1.x, which should happen during the next couple of days (as soon as I receive my board).