Apologies if this is documented elsewhere...
There appears to be a bug related to NXTComLSRead when reading multiple bytes - it's not clear whether the problem is in the firmware or in NXT-G (we're using the most recent firmware as of this date.)
I recently helped interface the NXT and NXT-G to an I2C device that returns 12 bytes during NXTComLSWrite. The device repeatedly sent the same 12 bytes (as confirmed on a logic analyzer) but the byte's-ordering changed in NXTComLSRead. We follow the Ultrasonic-sensor example - doing the Write, waiting for the 12 bytes to be ready, then reading. The byte corruption happens in four-byte groups - that is, ony four of the 12 bytes are wrong - either the first 4, the middle four, or the last 4.
The work-around was to follow "LowSpeed.GetStatus.vi" with three NXTComLSReads of 4 bytes each instead of one read of 12 bytes. Reading 12 bytes just wouldn't work accurately/repeatedly. Reading 8 then 4, or 4 then 8 didn't solve the problem. It seems
Reading 4 then 4 then 4 consistently allows us to retrieve the 12 bytes transferred during NXTComLSWrite.
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare