One potential issue: ar2 will be converted to uint8 if kind=None, and can still end up being passed to the kind="sort" method. Whereas if kind="sort", it will not be converted beforehand.

However, this never ends up happening in practice, since kind="table" will always handle boolean arrays, as their memory consumption is always under the limit.

Actually, it could happen, if ar1 is a bool and ar2 an integer array. ar2 could be over the range limit, and then ar1 will get converted to a uint8 if and only if kind=None, not kind="sort". But it would always use the sort method... Is that problematic or fine?

Its fine, but it would be great if you could make sure we have tests "documenting" how these are expected to behave (parameterizing the methods again ideally).

Sounds good.

Just so I understand, is np.in1d([True], [1]) == [True] the desired behavior, or would you plan to have it throw an error in the future?

It does not matter right now. We just make the test pass with whatever behavior current (or previous) NumPy had. If you think it should maybe fail, add a comment to that effect. But the day where this fails is probably also the day where np.concatenate() will fail for it. So I don't think a comment matters much (it would be a big, very intentional change anyway).