Agreed, the error message is misleading.

>>> import numpy as np
>>> np.maximum(3, 4, 5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: return arrays must be of ArrayType
>>> np.maximum(3, 4)
np.int64(4)

Its signature, like all ufuncs, is

maximum(x1, x2, /, out=None, *, where=True, casting='same_kind', order='K', dtype=None, subok=True[, signature])

Changing the ufunc signature to be kwd-only would be a large backward incompatible change. Maybe we could do it via a deprecation process.

I would be up for slowly deprecating not using out= for ufuncs in general. Could potentially escalate to a VisibleDeprecationWarning relatively soon, to make it easier for users to spot.

I would not be surprised if part of the reason for it not being kwarg-only, is that the speed difference between keyword and non-keyword use, used to be much bigger.

The actual change required is very contained, but in C (and of course it needs tests and tracking down the DEPRECATE pattern used elsewhere).

EDIT: This is very sprintable/attackable as such. There may be a longer tail of test fixes because we probably use the pattern internally. And at this time, consensus for the change has not been fully established.

I agree we should encourage keyword out, though I worry it is a lot of churn for not that much benefit. I guess the alternative is to just guard functions where people are easily misled -- minimum and maximum do seem good examples of that. A final alternative is to simply make the error message more explicit.

I'm also in favor of getting rid of the positional out parameter in ufunc. It it very difficult to properly annotate in the (numtype) stubs because of this, especially when there are more than one values like for divmod.

To illustrate, ufuncs with 2 inputs and 2 outputs currently require 13 overloads, and it doesn't even take the NEP 50 promotion rules into account yet, which would at least quadruple that (i.e. >=52 overloads): https://github.com/numpy/numtype/blob/1155b2582ab747dc7fcc71736a90912d650a5332/src/numpy-stubs/_core/umath.pyi#L1052-L1222
And in my most optimistic estimation, if we were to throw shape-typing in the mix, you can double that amount. The overloads for the different "dtype-like" types of the dtype parameter also aren't included yet, btw.

Now, given this combinatorial mess, try and imagine what the ufunc definition for scipy.special.ellipj will look like when fully annotated, which has nin=2 and nout=4 😅...

So to make long story short: Keyword-only out? Yes please!

Yeah, I think when I wrote it, I didn't think too much about how much code may actually be passing out as arguments. I can imagine a special case for minimum/maximum as they are more likely to be incorrectly used.
I also don't mind aiming for deprecation, but we should actually spend a bit of time to see if there are many users and then probably take it slow.

I honestly still like our old philosophy of just refusing to type undesired patterns. Also because that is an additional way to nudge users away from it. If we wish we would deprecate it one day (even if we may hesitate to do it), then not typing it feels very reasonable (maybe with docs to have at least some basis for that choice...).