html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/6806#issuecomment-1188966372,https://api.github.com/repos/pydata/xarray/issues/6806,1188966372,IC_kwDOAMm_X85G3i_k,4160723,2022-07-19T12:02:00Z,2022-07-19T12:02:00Z,MEMBER,"Ah ok I see, thanks! Yes I agree this may be useful.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1308371056
https://github.com/pydata/xarray/issues/6806#issuecomment-1188281362,https://api.github.com/repos/pydata/xarray/issues/6806,1188281362,IC_kwDOAMm_X85G07wS,4160723,2022-07-18T20:37:03Z,2022-07-18T20:37:03Z,MEMBER,"> This turns up in staggered grid calculations with xgcm where it is easy to mistakenly construct very high-dimensional arrays because of automatic broadcasting.

Do you have an example that illustrates this issue?

I'm curious to see if in that specific case using a custom index for staggered grid coordinates wouldn't work as an alternative solution. The alignment rules are pretty strict (same index type + same sequence of coordinate names & dims). Not 100% sure if that applies in the xgcm case, but in theory it would raise an error regardless of the join method if you try to align objects that have broadcastable coordinates with incompatible indexes.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1308371056