BUG: pandas concat does not match index names when concatenating two dataframes with a multiindex
- [x] closes #40849 
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry

Hello @taytzehao! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:







There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2021-05-26 13:39:41 UTC if you consider six indexes each with the combinations:

```
vals = [['i0', 'i1'], ['j0', 'j1']]
idx0 =  MultiIndex.from_product(vals, names=['First', 'Second'])
idx1 =  MultiIndex.from_product(vals, names=['First', 'Third'])
idx2 =  MultiIndex.from_product(vals, names=['Second', 'Third'])
idx3 =  MultiIndex.from_product(vals, names=[None, 'First'])
idx4 =  MultiIndex.from_product(vals, names=['Second', None])
idx5 =  MultiIndex.from_product(vals, names=[None, None])
```

It is not obvious to me what your PR is going to do do when it concats say: `idx1` with `idx3`, given that in some cases it will find a name that matches, and in some cases it won't, and in some case there isn't a name.

This needs tests for various cases, I think.

This might need complex logic but as a start it might be sensible to match index names only in the case they exactly overlap:

e.g {'name1', 'name2'} == {'name2', 'name1'}, and if it doesn't overlap exactly it falls back to the original?  https://github.com/pandas-dev/pandas/pull/41162#issuecomment-826761447  comment has been taken into consideration into this commit. > [#41162 (comment)](https://github.com/pandas-dev/pandas/pull/41162#issuecomment-826761447) comment has been taken into consideration into this commit.

can you describe qualitatively how you are handling the cases. what is the goal for different cases? also have you run any performance checks (asv) to ensure there isn't any performance degradation here? is any expected? > if you consider six indexes each with the combinations:
> 
> ```
> vals = [['i0', 'i1'], ['j0', 'j1']]
> idx0 =  MultiIndex.from_product(vals, names=['First', 'Second'])
> idx1 =  MultiIndex.from_product(vals, names=['First', 'Third'])
> idx2 =  MultiIndex.from_product(vals, names=['Second', 'Third'])
> idx3 =  MultiIndex.from_product(vals, names=[None, 'First'])
> idx4 =  MultiIndex.from_product(vals, names=['Second', None])
> idx5 =  MultiIndex.from_product(vals, names=[None, None])
> ```
> 
> It is not obvious to me what your PR is going to do do when it concats say: `idx1` with `idx3`, given that in some cases it will find a name that matches, and in some cases it won't, and in some case there isn't a name.
> 
> This needs tests for various cases, I think.
> 
> This might need complex logic but as a start it might be sensible to match index names only in the case they exactly overlap:
> 
> e.g {'name1', 'name2'} == {'name2', 'name1'}, and if it doesn't overlap exactly it falls back to the original?

agreed what is the meaning of all of doing this tyep of concat. I would prefer to raise in any non-completely obvious / non-ambiguous case. Ah .. never thought of that. Thanks.. will look into that @jreback , it seems the align function can only be used on ```NDFrame``` class. It utilizes the blockmanager for alignment. 

Unless, should the align function be implemented in the MultiIndex class? I am actually not quite sure why the test actions-38 fail. When I test it locally, the test passes. Can anybody give me some suggestion? This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this. Thanks for the PR, but it appears that this PR has gone stale and needs ideally a simpler solution as explained in https://github.com/pandas-dev/pandas/pull/41162#pullrequestreview-665645291 (or why a simpler solution does not exist).

Going to close due to inactivity, but let us know if you'd like to continue working on this issue.