We do have a couple of more caches like this, or Python object caches. I OK with adding such a function if it helps you especially if you want to use it for testing downstream.
I suppose it would make most sense if we cover most such caches.

If we want to semi-expose it, we should probably import it to a module other than _multiarray_umath and document it very briefly. lib.array_utils doesn't feel quite right, but maybe almost better than some others?

@ngoldbaum do you have a quick thought?

Maybe it would be better to simply disable these caches with an environment variable that gets checked once when NumPy is imported? That would add one extra comparison with an integer in the allocation fast path but I doubt that's a big deal.

We already have a USE_ALLOC_CACHE preprocessor directive:

Of course that doesn't help anyone who can't build their own NumPy, but also I'd be surprised if anyone doing this sort of memory leak debugging couldn't build their own NumPy. I'd be fine with adding a more generic NPY_USE_INTERNAL_CACHES environment variable and using that for all the caches that one might want to disable for memory debugging.

I'd be fine with adding a more generic NPY_USE_INTERNAL_CACHES environment variable and using that for all the caches that one might want to disable for memory debugging.

That works for me! Though if USE_ALLOC_CACHE is exposed as a compile-time option, that works too.