It feels like the index value should not come from a template but an internal option, but given that we currently do not have a mechanism to extend options, I would suggest to use an enum instead of an explicit integer to make the code a bit more expressive.

enum class MinMaxIndices : int8_t {
   MinIndex = 0,
   MaxIndex = 1,
};

Good idea. I added this + moved some things to lambdas instead of free functions.

If the comment of using enum is accepted, then use enum as template parameter.

Nit: Here OutputType is expressed as a lambda function, so should MinMaxType be also a lambda.

Similar comment as above on lambda vs MinOrMaxFinalize.

Maybe include tests of only hash_min and only hash_max.

I'm not sure there's a need to test the kernels separately, since they're being run separately by the nodes - I group them mostly because it's a lot of vertical visual noise to duplicate these tests otherwise (we should probably clean them up at some point).

I agree (thus the "maybe"), if it is already hitting those code paths independently which seems it is.

Extend test case to get min/max between NaN, Inf, null, value.

Done.

For the record, it's a bit of a pity to do a second registry lookup when arriving here.

Since we register min_max first, I've changed it to just pass the function to the init function, skipping the second lookup.

DCHECK that the result is valid?

"max" before "mean"

Thanks. I also fixed the output type column.