I had a chance to play around with the latest firmware over the weekend and I am fairly impressed. Several GUI issues I had reported were not mentioned in the release notes, so I was quite relieved that they had been fixed as well.
One issue I had noticed (but never reported) before the firmware update has not been corrected though. Incorrect data is saved when downloading a .csv file of the acquisition memory of a trace that has not been allowed to complete. I noticed this when using the scope for some ad-hoc datalogging with the timebase set to 500s/div, but it can be recreated with any timebase slow enough that you can hit Run/Stop before the full trace data is collected.
The attached examples were taken with Single trigger mode and Acquisition Record Length of 20MSa. The first one (scrprint1/plot1) was allowed to complete and the downloaded data appears correct, while the second one (scrprint2/plot2) was stopped early with the Run/Stop button. The .csv files are downloaded through the network interface and the plots are generated with Octave+gnuplot, and I have manually examined the .csv file contents to verify that the plots are accurately representing the data in the files. I'd upload the .csv files as well but they are ~500MB
The data content of the early terminated traces can vary - I know at various times I've seen random data, discontinuous data like shown in the second example here, and even continuous data that appears to be from the correct waveform but with incorrect phase/timestamps. I'm sure it is related to the previous operations on the scope, but I haven't quite figured out a pattern to it yet.
It is also interesting that the pre-trigger data is never shown on the early-terminated trace. On the trace that is allowed to finish the pre-trigger data is not displayed until after the trace completes, so it seems possible that there is some sort of post-trace processing that is being missed that leads to the download being incorrect.