Benoit Bovy

As an end-user you would only need to do `ds.load()` or `ds.compute()` and not care much about anything else. It is up to the index to define how to "load"...

I see. Would it be reasonable to add a `Dataset.load(load_coords=False)` option? And add a `Dataset.coords.load()` method for the case of loading the coordinates but not the data? This is not...

Assuming a multi-coordinate index like RasterIndex over x/y dimensions, `ds.xindexes["x"].load()` may look confusing: what about "y"? Some possible ways to make it less confusing: - In Xarray update `Indexes.__getitem__(self, key)`...

What I also find confusing is the generic term "backend" used here, especially that many things in Xarray may now be viewed as "backends": IO, duck array types, parallel computing...

In general I very much agree with your recommendations @shoyer! I just wanted to raise some minor concerns or questions, though. (note: I clearly lack of experience on this matter...

> Is there a branch with the dim= code on? See #8170

> Whichever we choose, it should always be recommended to compare with the enum and not with a direct integer, and if you follow that then the actual number does...

> Or more generally, should all the variables needed to construct an Index be preserved after the Index is created. If so, we'll need a new rule around coordinate variable...

@dcherian did you experiment further with this? I might want to take a stab at it, maybe in a draft PR. > CF saves three : left bound, right bound...

Nice! Yes CF-compatibility will probably still require having an Xarray index (lightweight wrapper) separate from `PandasIndex`. Or maybe we could get away with a CF codec when https://github.com/xarray-contrib/cf-codecs will be...