It occurs to me that the calibration errors we all see might not necessarily be in the .qct files. The .qct map files might be perfect. Perhaps the observed errors are down to inaccuracies in the 'invisible' reference that the cursor uses for it's readout?
Unfortunately (?) not. If you have a license for any 25k mapping for the desktop try loading them up there, the cursor is visible and you can easily see just how far off it is (you can then compare that to older small maps to prove it should work).
Wherever the errors come from, my own observations are that for the Lake District 1:25k map, the error is fairly consistent across the whole of the National Park.
This is a fairly small map, compared to the whole of GB, so you would expect the error to be much smaller, probably into the tolerable range. When I say 'expect' I mean both compared to previous smaller maps and to what I said above (if that's on the money).
I am curious to know how OS master files are checked for accuracy. What reference is more accurate than the OS master files (whatever they are) that Jason refers to?
Yes, "don't blame us - maybe OS put the mountain on the wrong grid square" :-) I think you need to regard that suggestion with some derision.
How accurate should the 25k maps be? I assumed that in this day and age they'd be to within a metre or so.
Depends how you measure accuracy. I'll talk here about the alignment of the actual map images to the grid (because that seems to be the problem here, we know that because even the blue grid lines on the map are out of position), not the accuracy of features on the map. OS supply the maps for raster/backdrop mapping in square tiles aligned to the British grid so in terms of that grid they are 100% accurate. If you want to know accuracy for grid to GPS positions that depends how it's converted. OSTN02 converts British grid to ETRS89 (essentially WGS84) with an acurracy of 0.1m. Helmert transformation is described by OS as limited to applications with 5m accuracy. Having tested converting some British grid values to WGS84 via different methods to see which produces the same result as memory map I've concluded that memory map uses a helmert transformation when they convert from OS data to QCT data (and as mentioned before they don't ship the data required to do an OSTN02 conversion back again for displaying British grid, so we already knew it couldn't be that). This would mean 5m accuracy for the maps, assuming everything else is done correctly. I'm still making some assumptions about their data source of course, but I'm fairly sure what package they will have from OS. As I say my background isn't strictly in mapping but I do have some connection, and I'm lucky enough to have access to the entire set of OS raster tiles :-)
Perhaps someone could explain how the cursor information and .qct files relate to each other?
I did above, well not in a lot of detail but if you want more look for the unofficial specification. Your cursor position is over a particular pixel. The program contains a formula and the map contains some data which combined with the pixel position is used to calculate the WGS84 position. This is where I think the problem is. The QCT file doesn't contain British grid reference for the 4 corners, if it did and a Helmert transformation was used on that, you could expect 5m accuracy (that means out by 5m at worst, most of the map would be better). The QCT doesn't store British grid though (as it wouldn't work for non-GB maps), it stores some system for calculating a WGS84 position directly and we don't really know how that is done (we only have information on the last bit of the calculation).
My suggestion for fixing the maps would be to extract the map as an image (tools are out there for this) for just the section of the map you have bought (assuming a reasonably small size area). Load the image into memory map (would require the 3rd party import license) and calibrate the corners with WGS84 positions (worked out using OSTN02) and export this as a QCT file. You could then load this on your tablet/phone and have a pretty accurate map. Not actually tried this myself but the logic is sound, might have a go at this later today if I get chance.