Thanks for the clarifications David.

I'm inclined to leave down stream changes (such as to mixin/propertiesdata.py) to seperate PRs, so as to keep the changes to Data self contained.

Very sensible. In which case, we can sort that post-merge to master, though maybe you can update the four cases of mask_invalid still contained in a docstring example under data.data itself, as shown in my code snippet above, so as not to advertise the deprecated method?

Keeping tabs on the API changes is definitely a good idea. Perhaps I'll make a start my adding some to the table in #295, from whence they could end up in other issues (like #182).

Great. I see you've updated the table to mark such changes in the third column (looks like I somehow guessed the right number of 'notes' columns we'd eventually have use for!), nice idea.

So, apart from perhaps addressing the minor issue of those four cases of mask_invalid in the data examples, which is optional, this is good to merge. Thanks :)