This looks good to me as an alternative to #6706 that also addresses __array_ufunc__ and binary operations. Though, if this does end up being preferred over #6706, some tests with a mock subclass would be useful here.

@jthielen I'll add tests here specifically for binops, ufuncs, and __array_function__ on a couple toy subclasses.

But I think @shoyer is right:

I think it would be a good idea for the broader dask development team to make an intentional decision about whether subclassing dask data structures is a supported feature or not. Implementation inheritance imposes a cost in complexity that may not be worth the trouble.

It's hard to say where to draw the line on testing support for inheritance though, so I'll focus just on the things this PR is meant to address.

Apologies for the delay in review here @gjoseph92. I'm hoping to take a look later in the week.

In the meantime, #6734 came up. Do you know if this affects it at all (at a glance, I think the answer is no)?

In the meantime, #6734 came up. Do you know if this affects it at all (at a glance, I think the answer is no)?

Thanks for the mention of that issue @TomAugspurger! I've added a comment about what I think is going on there. If it is what I think it is, then I don't believe it affects this PR.

@gjoseph92 checking in here, should we merge main into this branch and see the status of CI, or is this work stale?

Might as well merge main, I think this is still a valid change. I can tell you it's been running in production for over two years and never caused issues there :)

Ci is green after merging main. @TomAugspurger since you initially reviewed this PR, would you mind giving it a last check and if things look good we can merge it in?

Thanks @ncclementi @TomAugspurger, I never thought this would end up getting in!