re: Going back though, I think what prog and I discussed earlier seems to be a plausible explanation for this.
Maybe, Maybe not. The reason it's important to know if it's just a message count of '1' is as follows....
The only messages that are protected by secure CRC are DF11*, DF17, DF18 and DF19. So barring any massive corruption (> 2 bits) these should be decoded properly. The ICAO of aircraft can then be safely extracted from these frames. With all the other DF's, the decoded CRC is not zero - it's the ICAO of the aircraft that transmitted it. Therefore these other frames cannot be safely decoded in isolation because the software can't know if that aircraft is actually present, or if it's a corrupted frame that produces a different CRC, and hence a different aircraft.
To solve this problem, most software keeps a whitelist (the opposite of a blacklist) of aircraft ICAO's which have been observed recently with CRC secure DF11/17/18/19. Then, when one of the other DF's arrives, it can check if the ICAO decoded from the insecure frame is in the whitelist. If it is, then the message is probably Ok. If not, then the message is discarded. It is vital that the whitelist is kept pure, otherwise spurious decodes of other DF's can and do get through.
What all this means is that you should only ever see messages for ICAO's for which DF11/17/18/19's have been successfully decoded. Altitude or Squawk's come from DF4/DF5/DF20/DF21, so if you see these randomly then there must have also been a previous 'valid' decode of a DF11/17/18/19 as well, so at least 2 frames must have been received using that ICAO. Lat/Lon (usually) requires 3 frames. Therefore it's difficult to understand how a single (corrupt or not) frame can result in an ICAO, 450kts and FL300. That required at least 3 frames I think.
If two aircraft with similar ICAO's (one bit different) are both being received at the same time then it is possible for corrupted messages from one aircraft to be wrongly allocated to the other. I doubt much can be done about that without much stronger/stricter decoding of the RF signal possibly including RSSI for each bit in the message, but that will incur significant extra processor workload. Sounds like Youssef is on the case though.
*Providing II/SI == 0;