EDITED to update with items from @eric-wieser and @shoyer. Feel free to edit to add other items.

A reminder of clean-up after #8247 that could most usefully be done:

• Currently, arguments in ufuncs are normalized in get_ufunc_arguments (in ufunc_object.c), well after a check for an override is done; the latter code separately normalized arguments in override.c. Obviously, it would be better if only one of those was done (to the extend possible). As part of this, the type of exception raised should also be made consistent with python, i.e., TypeError for too many/too few arguments, things occurring both as positional and keyword arguments, etc.)

• BUG: __array_ufunc__ on arguments like axis would also override the ufunc (TST: __array_ufunc__ cannot be overridden on axis, etc. #9107).

• np.dot and np.matmul are no longer overridden, but it would be good to override np.matmul in particular (as it implements a binop). This would need (1) turn np.matmul into a generalized ufunc (or have it use a new gufunc, after prepending/appending of axes as appropriate); (2) use the same generalized ufunc where feasible inside np.dot (and ndarray.dot), so that the most common cases can be overridden (for other cases, we might want to error on the presence of __array_ufunc__).

• (@eric-wieser) Set the __name__ field of the generated NDArrayOperatorsMixin methods (MAINT: Set the __name__ of generated methods #9012)

• (@shoyer) Need to switch ufunc overrides to always raise TypeError if any arguments set __array_ufunc__ = None (Ufunc overrides should always raise TypeError if any arguments set __array_ufunc__ = None #9011)

• (@shoyer) Choose the recommended way of implementing binary ops (calling the ufunc directly, or calling __array_ufunc__), and clarify guidance in the NEP (DOC: update binary-op / ufunc interactions and recommendations in ufunc overrides NEP #9027)

• (@shoyer) Backwards compatible mixin like NDArrayOperatorsMixin as a separate project (Backwards compatible mixin like NDArrayOperatorsMixin as a separate project #9016).

• (@shoyer) BUG: no way to override matmul/@ if __array_ufunc__ is set (BUG: no way to override matmul/@ if __array_ufunc__ is set #9028)

• (@mhvk) BUG: no way to override __eq__ for structured ndarray (BUG: ndarray.__eq__ does not respect overrides for void #9153)

• ENH/MAINT: let ndarray.__array_ufunc__ be the overall gateway to applying ufuncs on ndarray; that way, this function can just participate in the different trials of objects to see if they can handle the ufunc. As part of that, should they just turn subclasses into regular arrays (since those have had a chance anyway? see discussion in Misleading __array_ufunc__ error #9079)

• (@shoyer) Document the table of ndarray arithmetic special methods and corresponding ufuncs in the proper docs (e.g., reference/array.classes.rst, not the NEP).