Thanks for looking into this. This is not a problem just for BLANK, but also for BZERO and/or BSCALE (really, any header keywords that affect how the data should be read). I'm thinking maybe do_no_scale_image_data should include ignoring BLANK because for the most part you would want to ignore blanks replacement for the same reason you'd want to ignore BZERO/BSCALE--faster access to the raw data.

On the other hand, I have had in mind for a while (I think there's a Trac ticket for it somewhere) a special ndarray subclass of FITS images that incorporates all the scaling issues and can do so on a per-element basis (perhaps with optional caching of the results). That would allow this to work a little more transparently, even with mmap.

Related to #2307.

Just remembered about this PR. As @mdboom wrote #2307 added the suggested ignore_blank keyword. And #3865 made further significant improvements to how the BLANK keyword is handled (including also excluding it when do_not_scale_image_data=True, and also properly writing blank values on output).

On the other hand, wouldn't it be good to have a method like get_raw_data (similar to _get_raw_data but with a simpler signature)?

I think a .raw_data attribute would be good to have on a per-HDU basis (no messing around with do_not_scale_image_data). As my prior comment wrote the ideal is some kind of container class for FITS data, but in the meantime a .raw_data attribute might be useful. I'll open a separate issue about that.