I think the intention here is to only use assert_array_equal on ndarrays. So could you modify your code to do

np.testing.assert_array_equal(np.array([['a', 'b'], ['c']], dtype=object),
                                   np.array([['a', 'b'], ['c']], dtype=object)

?

Indeed, I am not sure this (or possibly even the general issue with ==) is an unintended side effect, as opposed to just a bit confusing/unexpected on first sight.
The main issue I see is the matplotlib one in gh-15047

I think the intention here is to only use assert_array_equal on ndarrays.

The issue I see is that previously working / valid assert_array_equal code now emits a warning, which can break things downstream. If assert_array_equal is in fact meant to work for object-array-like things and we were just getting lucky before, then I don't see why it should emit a warning when you use it with one. If it's not meant to be used with object arrays, it would be better to catch the dep warning and emit a new one saying "assert_array_equal is not meant to be used with object arrays", which will then later automatically become an error when "object-array-like without explicit dtype='O' is an error" lands in np.asarray/np.array.

FWIW it seems like assert_array_equal not working with object arrays is a bit odd, since from my user/dev perspective object arrays are more or less just an ndarray with a particular dtype that will triage the underlying == operation.

So could you modify your code to do

Yes this is a possible workaround. The issue is that there could be tens or hundreds of such cases in a given code base. Then of course you could write your own a assert_array_equal wrapper to safely do this casting, etc. But then the issue is that there are many codebases, and any repo that has this assert_array_equal on object-array-likes will have to do this. For us it was easy enough just to change our handful of instances to assert a == b (since we just had lists of lists of strings, so == worked fine). But this might cause more systematic problems in the ecosystem.

Adapting assert_array_equal to squash the deprecation warning and cast in a future-compatible way, or explicitly disallow object arrays (via deprecation cycle with warning), might be a nice thing to do for folks. But this could also be enough of a corner case problem that it's not worth dealing with. I'll close since this might be the case. At least others might find this issue now if they search, and if it they hit the problem they can chime in, too.