Caveat: we are avoiding these I2C sesnors until May. Others in our lub are rolling the dice in my mind, but we were on that early release version of Robot C with the I2C and had our robot spin uncontrollably at a competition even with the competition switch set to disable. So we had similar issues with this as well.
If you look at how I2C communication works, you have to send messages out to poll each device for information. There are some old posts on this when the I2C sensors came out so look them up.
We put in some timer delays in our loop to let the I2C sensor get another value and that helped somewhat but it seemed to be more like playing the lottery than a real fix. The idea was that we wanted to ensure we were not interfering with this polling communication over the serial communication to the I2C sensors (we had 2 in the chain). Unless there's proper semaphore blocks on the sensor values you're reading in the underlying RobotC code masked from you, could you be reading while it's writing or in the middle of communicating and parsing the I2C causing some nastiness? Or it could be in the I2C communication handler with some memory out of bounds or other nastiness. It could be a lot of things.
So just a thought and sorry it's not a definative fix. Otherwise it might just be some other bug related to the I2C.
Also, doesn't I2C work pretty reliably for Mindstorms on Robot C? I've never used it so I have no idea. What makes Vex different? Cortex hardware/firmware and SensorValue masking the underlying I2C communication. If successfully masked it's wonderful.
Hence we're back on quad encoders for worlds.... On the to do list for May though! Those I2C sensors have huge promise.