Thanks for opening this @burnpanck .

I notice in tests/test_accessors.py we also separately set force_ndarray_like=True

That seems odd in that it doesn't fully decouple the tests from the code, and also seems like it might be making this PR misleading by causing tests to pass in the CI that would not work in user code?

Didn't spot that one. However, the tests still pass on my machine. To me, this suggests that force_ndarray_like is really not needed for any of the core xarray/pint interop to work. The only case that has been offered is the automatic coercion of a scalar quantity into a zero-dimensional array in the construction of a DataArray. But I strongly suggest that we add a test for that if we even want to claim that this is an actual feature.

As I pointed out in #216 (comment), it is possible to use pint + xarray without pint-xarray, so most of the tests that do check compatibility live in xarray's test suite (for now, there's the desire to move those tests here once we have a replacement that still does extensive checks of the duck array compatibility).

After changing the unit registry of these tests to have force_ndarray_like=False 107 tests are failing, so clearly this is important for pint support in xarray.

it is possible to use pint + xarray without pint-xarray

I'll have to process that. I'm wondering why one should be using pint-xarray in the first place then. I'll try to have a go at reproducing those failing tests in xarray so I understand better.

pint-xarray is a glue / convenience package: while it is possible to use (most of) pint + xarray without pint-xarray, it is not very convenient to do so: creating quantities, converting between them, and serializing back to array + attribute would be very complex otherwise (however, this will change with #163, which will allow having units on indexed coordinates, something that currently is not possible).