Let me shed some light on this behavior. Your RVR appears to be perfectly normal, though this corner case can certainly be confusing. The firmware follows this rule:
If stopped when a new drive command is received, turn to within (IIRC) 5 degrees of the target heading before driving forward. Without this, the corners on your locator plots would be noticeably curved.
On the first move, RVR is already facing the target heading and the entire driving time is spent traveling forward. On subsequent moves, there is a 90 degree turn occupying some of the specified driving time. You can verify this by offsetting all the headings 90 degrees to force an initial turn.
If you believe that you followed one of our example activities exactly, then we should modify the example to fix this. Can you send me a link to the specific example you were following? Being on the firmware team, I’m not very familiar with much of the supporting content for RVR.
As an aside, latency from the BLE connection should generally be quite low, on the order of tens of milliseconds. This is occasionally higher on some devices due to issues with particular manufacturers’ Bluetooth implementations, but I wouldn’t worry about it in your case, based on the observations you’ve shared so far.
I should also mention that RVR has much higher precision in other drive modes that are not yet supported by EDU. The Raspberry PI Python SDK can send drive to position commands, which I’ve measured at 5mm of final position error driving a half-meter square on a hardwood floor. This is planned to eventually come to micro:bit as well when we have the bandwidth to revisit that platform.