The behaviour is likely caused by the fact that the indexes generated for the coordinates are no longer strictly equal, therefore where() picks only the two outer cells of each dimension.

Yes that's right:

```python v32.indexes["x"].intersection(v64.indexes["x"])

Float64Index([0.0, 1.0], dtype='float64', name='x')

```

I think the issue is more general than where() and relates to the alignment of Xarray objects with 32- vs 64-bit indexed coordinates:

```python xr.align(c32, c64)

(<xarray.DataArray (x: 10)>

array([0. , 0.11111111, 0.22222222, 0.33333334, 0.44444445,

0.5555556 , 0.6666667 , 0.7777778 , 0.8888889 , 1. ],

dtype=float32)

Dimensions without coordinates: x,

<xarray.DataArray (x: 10)>

array([0. , 0.11111111, 0.22222222, 0.33333333, 0.44444444,

0.55555556, 0.66666667, 0.77777778, 0.88888889, 1. ])

Dimensions without coordinates: x)

xr.align(v32.x, v64.x)

(<xarray.DataArray 'x' (x: 2)>

array([0., 1.], dtype=float32)

Coordinates:

* x (x) float64 0.0 1.0,

<xarray.DataArray 'x' (x: 2)>

array([0., 1.])

Coordinates:

* x (x) float64 0.0 1.0)

```

A possible solution would be to handle this special case internally by converting one of the index according to the dtype of the coordinate labels of the other index, similarly to what we are currently doing for the labels that are passed to .sel() (#3153). This should be pretty easy to implement in PandasIndex.join() I think.

However, I'm also wondering whether or not we should consider this as a bug. It would make sense to have a behavior that is consistent with .sel(), even though it is not a free nor transparent operation (implicit creation of a temporary pandas index). But how about .equals()? I.e.,

```python v32.x.equals(v64.x)

False -- Should we return True here?

```

This would be quite weird and wouldn't match the Xarray, Pandas and Numpy behavior below:

```python v32.indexes["x"].equals(v64.indexes["x"])

False

c64.equals(c32)

False

np.all(c32.values == c64.values)

False

```