This is a good example of why the list of files to be sanity-checked,
should rather fall on the side of easyconfigs, rather than easyblock;

AFAIK, George shares the same view like me, but not the Ghent team;
can we guys elaborate on this to find the solution that makes us all thing it is optimal?

My stance is that, in the name of orthogonality, over time the list of files to check can expand arbitrarily, and that should not end up as spam on the easyblock (I view the easyblock as an engine fed with easyconfig fuel ;-)

This is a good example of why the list of files to be sanity-checked, should rather fall on the side of easyconfigs, rather than easyblock;

After thinking a bit, I agree. I think it would make sense to put anything which might be expected change from one release to the next in the easyconfig.

@ajdecon: I agree that simply removing npp is a viable option here, since the list is already non-exhaustive anyway. So, I'll merge this in, thanks for the PR!

We have consistently defined custom sanity check paths in easyblocks because it's the correct place, in our view. Anything that is required to make a build successful should be included in the easyblock, and the easyconfig file should be kept as simple as possible (note: we could make it even more minimal, by moving homepage, description, etc. to the easyblock as well). Usually, the version-specific differences in sanity check paths are fairly minor. This policy really helps with the maintainability of easyconfigs (especially in the absence of fat easyconfigs, i.e. one easyconfig per software package).
That being said: sanity check paths that are specified in easyconfig files always get preference over what is specified in the easyblocks, so the kind of support you want is actually already there...