I also thought each serial port had it's own buffer and one shouldn't interfere with the other.
They do have their own receive buffers, and receiving on one does not interfere with the others.
if I understand correctly, is one buffer is reading data and the second buffer basically buts in so it can read it's data stopping the first buffer from completing its read.
Actually, it is the printing that prevents processing the receive buffer.
When you print, characters go into a transmit buffer. Compared to the processor speed (MHz), serial is very sloooooow (KHz). When you first print something, the first character starts going out. But before the first bit of the first character has even finished, the sketch has more characters to be sent. So they go into a transmit buffer. As the characters gradually get sent, they are removed from the transmit buffer.
But guess what happens if you try to print some more and the transmit buffer is full? Your sketch waits until there is room for the new print characters. It's not obvious, but your print statements have "blocked" the Arduino until the transmit buffer has room for the new print characters.
While the Arduino is twiddling its thumbs, the GPS device continues to send characters. They get stored in a receive buffer, waiting for some part of your sketch to call GPSserial.read().
Again, guess what happens if the receive buffer is already full and the GPS send another character? The Arduino drops the character. No room! This is an "input buffer overflow". Now the GPS sentence is only partially received, and it will not be parsed correctly. The Adafruit_GPS library will still say it's an ok sentence, even though characters are missing. 
This is one reason I wrote NeoGPS.
So it is the prints that prevent reading quickly enough to keep up with the GPS device. This is a fundamental problem with other libraries' examples. It is very common for new programmers to break these examples with (what appears to be) a simple modification.
How would I synchronise the servo references that I'm sending to the rover? I assume if I read from serial1 while GPS is updating I would have the same issue, actually I have. Currently I only send them once per second, that prevents the serial writes from over lapping. But on the rover side I want to read them as fast as I can to minimize the response delay.
I'm not sure I understand the complete picture, but it sounds like:
-
You want to send commands from the base station to the rover frequently. Via Xbee? How often?
-
The rover must process the commands to control servos.
-
You want to send location from the rover to a base station less frequently. Once per second, via Xbee?