I’m pretty sure the problem is a race condition.
The gps.c file consumes 1 byte at a time from the UART polling, and parses it (ultimately calling the gps_data_convert() function which was fixed). However, the i2c callback (i2c_slave_callback) is invoked whenever the rePhone Wire library asks for some data, and there is nothing to protect the data field GPS_RMC_Data from being read by i2c at the same time it is being rewritten by gps_data_convert(). The default gps frequency is 1Hz, so that string is being rewritten every second.
Given that the string in GPS_RMC_Data is both the source and the destination for gps_data_convert() makes it especially problematic. I think if different strings were used, at least if i2c_slave_callback() was reading the string while it was in the middle of being written by gps_data_convert(), it wouldn’t be as incorrect.
I believe the correct fix is to change gps_data_convert() to write out its converted string to a different buffer, the buffer which i2c_slave_callback() reads, rather than re-using the buffer which is initialized from the UART data. That’s an easy fix, achievable by creating 2 GPS_RMC_Data static variables, updating the gps_data_convert() to read from the existing one, and write out to the new one, and let the i2c callback read from the new one.
A better, but more involved fix would be to move all of the NMEA string parsing to the RePhone side of things, and change the gps driver logic on the GPS board to simply have a buffer to hold each of the 6 NMEA string values, which it overwrites as each new one comes in, and use a standard arduino gps parsing library at the RePhone side.