This is my attempt to address what is pointed out in #2238 and its precursors, within PlotDataItem's framework of original, mapped and displayed data sets. Many thanks to @StSav012 for continuing to bring this to our attention and for submitting PRs to address it!

I share the opinion that a user selecting [CSV export] is almost certainly interested in the original data, and that it has been accidental that the output now provides the processed data, potentially mapped as log10.

This PR changes the CSV exporter to access the original data set kept by PlotDataItem through a new interface getOriginalDataset(). If this is not available, for example in a user provided variant item, it will fall back to getData(), which should be guaranteed to exist and provide the previous behavior.

With this PR we officially commit to maintaining a copy of the original data in PlotDataItem, but that has already been necessary anyway.

I do not think this commitment extends to other items like PlotCurveItem, and does not block the potential implementation of proposed fast-append code that works directly on the Qt path, without necessarily maintaining a "raw" data set. In the interest of performance, we do not want these items to implement (log-)mapping functionality independently. Where this is needed, the user code should go through PlotDataItem. In the long term, we might want to reconsider the interface declaration 'plotData' and add some distinctions there.

@StSav012 , please let us know if this addresses your issue, I don't have a good test case right now.
I'll be happy to work with you on the fine-tuning. Sorry to bypass your own PR, but I currently think that the approach here is less intrusive for the internal workings of the library, and less likely to conflict with custom user code.