OK its working.
The fix on post #8 is working fine at 57.6k with any buffer size i.e. 160
It appeared not to work the other night when I upped the rate as the GPS cmd to change baud was wrong. 
160 ish is a good buffer size as it lets you have 2 lines of NMEA data in hand while you talk to an SD card or do other things.
128 looks a bit small, 256 may be too big for some.
256 does actually work as the 8bit math it naturally mod 256 if you know what I mean.
Another possible optimisation I observed is that the delay for eating up the stop bit could be just over half a bit as we are already looking at the so called middle, so it should only take another half a bit or so before we get back to the MARK state.
I guess we only need to miss the edge of the STOP if it happens to be changing from the state of the final bit.
Any one know how to get this forwarded for consideration in the core ?
There should be a least a big WARNING or explanation that the current code is highly optimised for buffers of 64, 128, 256, and it certainly doesn't work with other values at 19.2k or more
... Simon