Yeah. I was using a NANO clone that uses the same CH340 chip. I wound up replacing the nano with an Uno clone with a 16U2 and flashing the updated firmware. The error doesn't happen often, but is not predictable as to when it will happen. Luckily I found the problem when doing a dry run on a 3D milling test. I had the step-over on parallel passes set for 0.001" step-over and got an error in my streaming program about 30,000 lines in on one dry run. I re-ran it and it completed successfully, but I started investigating. At first, I thought it was probably my interface program that I wrote myself. I set GRBL to echo the received lines and set up a sniffer program for the serial port and found that when the error occurred, the line was sent correctly from the PC, but GRBL echoed back incorrectly. I then did a loop back test where the lines were sent and immediately looped back to the PC, taking the Arduino out of the loop and the error was there. That test confirmed it had something to do with the CH340. At this time another GRBL user got involved and he was able to replicate it on the 16u2, but not at 115,200 baud. He was able to find the code for the firmware for the 16u2 and made some modification that fixed it on the 16u2. The reason there isn't a fix for the ch340G is because the firmware code for that chip isn't available. I actually e-mailed the company that makes it asking for either a fix, or the firmware so that it could be modified, but never got a response. Basically what happens is as follows:

2 consecutive lines like:
G1 X1.2345 Y9.8765 Z4.5678
G1 X2.3456 Y8.7654 Z5.6789

might only get through as
G1 X1.2345 Y9.8754 Z5.6789

where the text in bold I is just dropped. The above example would not generate an error, but the machine would go to the wrong place. It is random what text gets dropped, and sometimes it still looks like a valid command to GRBL, and other times it doesn't and generates an error.

Alex Holden on the GRBL site is the one who fixed the 16u2 firmware and in his testing he found that at 115,200 baud the 16u2 seems to work fine without modification. I would still recommend re-flashing the 16u2 with his modified firmware. I have been using it since he posted it and it has been flawless. I tested his modified firmware using a 1 million line g-code file and could generate an error in about 4 days of running in a test setup, looping through the file over and over and over.