More specifically:

Should we change this? It is quite trivially done, but perhaps I am missing a reason for omitting the non-override types.

Realistically, without these other changes in NumPy, how would this improve code using __array_function__? From a general purpose dispatching perspective, are there cases where you'd want to return NotImplemented based on types that don't implement __array_function__?

I think, yes, that would be the closest analogy to the python operators. Saves you from having separate cases for types that have and do not have `__array_function__`.
 
I guess this might help if your alternative array class is super-explicit, and doesn't automatically call `asmyarray()` on each argument. You could rely on __array_function__ to return NotImplement (and thus raise TypeError) rather than type checking in every function you write for your alternative arrays.

Indeed.


One minor downside would speed: now __array_function__ implementations need to check a longer list of types.

That's true.

Another minor downside: if users follow the example of NDArrayOperatorsMixin docstring, they would now need to explicitly list all of the scalar types (without __array_function__) that they support, including builtin types like int and type(None). I suppose this ties into our recommended best practices for doing type checking in __array_ufunc__/__array_function__ implementations, which should probably be updated regardless:


Also true. It makes me wonder again whether passing on the types is useful at all... But I end up thinking that it is not up to an implementation to raise TypeError - it should just return NotImplemented.

If we'd wanted to give more information, we might also consider passing on `overloaded_args` - then perhaps one has the best of both worlds.

All the best,

Marten