Tom Nicholas

I would be okay with this - what say you @keewis?

If we are going to make this change then we should 100% do it before I release that belated blog post. I would be happy to implement this if we...

> The one place `as_numpy` doesn't work is when it's `DataArray(pint(dask(numpy)))` "Doesn't work" as in `.pint.magnitude` returning a DataArray would be the only way to conveniently get back `DataArray(dask(numpy))`?

Looking at this further this is actually quite tricky. Currently the code will attempt to convert all variables in the xarray object, collect the errors, and then raise a `ValueError`...

Fundamentally I just feel quite strongly that errors caused by incorrect units should raise a pint unit-related error. It would be consistent with `Quantity`, it allows for catching unit-related errors...

> we'd define a PintExceptionGroup That looks cool! If that allows us to raise both types of error then it seems like it could be a good solution.

> What do you think about postponing this feature until there's a bit more support? Totally fine with postponing this!

> a helper for coordinate unit conversion. So a `da.pint.coords_to`, that gets called within `da.pint.to`? Also what about `UnitRegistry().wraps`? Do we need a xarray equivalent for that? Would that help...

So as a to-do list, that would mean one positional arg for the data and multiple keyword args for the coords in `da.pint.to()`, then all keyword args for `ds.pint.to()`: -...

I definitely think that's in scope for this package, at least until some more general solution for reprs of all wrapped arrays is implemented upstream. Monkey-patching actually seems like a...