issue_comments

That's true,join="exact" would've raised an error, which would've been less confusing perhaps.

If we do want this use-case to work out of the box, then I too agree that a new top-level method would be best. stack would've been a good name but that;s taken.

Or indeed at least make it clearer in the docs that something like drop_indexes or reset_coords should be used first in order to skip auto-alignment for some variables.

I think we should do this regardless. I don't know of anywhere in the docs that these kind of subtleties with concat are clearly documented.

I guess easiest for a concat version with no auto-alignment would be to drop the index when such case happens.

Right - in this case that would have given the intuitive result.

We could get halfway to a better xr.concat by changing https://github.com/pydata/xarray/issues/2064 IMO.

I propose join="exact", data_vars="minimal", coords="minimal", compat="override"

That wouldn't have helped with this specific issue though right?

We could get halfway to a better xr.concat by changing the defaults IMO.

I propose join="exact", data_vars="minimal", coords="minimal", compat="override" 1. this would only concatenate variables that have concat_dim (if none do, then I think it will just concatenate all of them?) 2. It would skip any expensive equality checks and https://github.com/pydata/xarray/issues/5381

This would also drastically improve open_mfdataset by default. It will be pretty backwards-incompatible though.

In general I also find that xr.concat is a powerful feature (incl. auto-alignment and merge options) at the expense that it may sometimes (often?) be hard to reason about. Would it make sense to have a simpler version? To avoid making xr.concat signature even more complicated, maybe another top-level function like xr.concat_noalign? Or any suggestion in #7045 to deactivate auto-alignment Xarray-wise. Or indeed at least make it clearer in the docs that something like drop_indexes or reset_coords should be used first in order to skip auto-alignment for some variables.

I don't really know what I would prefer to happen with the coordinates. I guess to have created a time coordinate of size {new: 2, time: 4, cols: 2}, but then I don't know what that implies for the underlying index. @benbovy do you have any thoughts?

I guess easiest for a concat version with no auto-alignment would be to drop the index when such case happens. (note: one problem in your example is that the Xarray data model still does not allow having a multi-dimensional "time" variable with "time" as also one of its dimensions, but this could be now relaxed).

I've been also wondering whether some kind of NDPandasIndex would make any sense, i.e., a n-d coordinate variable with an internal 1-d (flattened) pandas index and some logic to convert between those n-d vs. 1-d spaces. This is the kind of approach used in xoak for using a kd-tree with coordinates of arbitrary dimensions, where labels in the form of nd-arrays for each coordinate are mapped into the [n_points, n_coords] shape (and inversely for getting the integer indices back as nd-arrays). This works well for point-wise indexing, but I doubt it would be very useful beyond that (e.g., slicing, etc.).