> I've matched the interpretation of mdtol used in the aggregator class.

Yes I got that !

Regarding the floating-point tolerance though, I'm still a bit concerned
( though I have tried + failed to construct a case that actually  behaves "wrong" )...
It still seems to me that this test is right "on the edge" and vulnerable to tiny floating-point errors:  
I'm thinking of cases where the user knows the size of dimension you are collapsing over, and wishes to set "how many missing data" is acceptable :  In practice a user "should" take account of this in setting mdtol -- for instance "mdtol=1.01 / 360" to ensure that 1 point missing in 360 will pass ok.  But in practice people may well not do that...

For example, in your own testcase you put mdtol=0.25 and then expect it to *not* mask where only one out of four corners is missing -- but according to current the calculation that is *not* guaranteed and it might quite reasonably "just" fail in that case.  It actually will fail if you replace > with >= in the test, which I think is a bit of a warning note for floating point calculations.
All the same, the *intent* here is surely clear : "allow up to one of four points to be missing (but no more)".  
So I'm suggesting we should add a tolerance term, which allows a number of missing points up to and including "int(n_elem * mdtol)", but fails at that-plus-one.