Presumably ufunc.accumulate should acquire this too?

This would be usable in masked arrays as well, right?

Sounds reasonable, although we'd need to figure it how to handle the case where axis is passed and the mask has inconsistent sizes (leading to a ragged array).
Maaked arrays could be rewritten to use this mechanism, yes.

I'd argue that for consistency with other uses of where, the resulting array should not be ragged, but be holey in the same way that np.add([1, 2, 3], [4, 5, 6], where=[1, 0, 1]) -> [5, 0, 9]. So np.add.accumuate(arr, where=m)[m] would be the same as np.add.accumulate(arr[m]), and the other entries would presumably be zero.

Hmm, the semantics here are ambiguous to me.

ufunc(a, b, out=c, where=w) means c[w] = ufunc(a[w], b[w])

Would ufunc.reduce(a, out=c, where=w) (a 2d, w 1d) mean:

• c[w.any()] = ufunc.reduce(a[w,:]) - only reduce the normalized rows where we requested an output
• c[w] = ufunc.reduce(a[:,w]) - only reduce the normalized rows where we requested an output
• c[:] = ufunc.reduce(a[w,:]) - always write to all outputs, but write the identity for empty rows

I think you were proposing the last one of these, but the semantics of where for normal ufuncs would lead to one of the first ones.

To be honest I had not thought about >1d semantics at all.

reduce now has a where argument (see #12644), so closing (in principle, accumulate and reduceat could gain it too, but let those get there own issues).