BUG: partial indexing a multiindex with repeated keys isn't consistent with desugared version

[wence-]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd
from pandas.testing import assert_frame_equal
df = pd.DataFrame({"a": [1, 1, 2, 3], "b": [1, 0, 1, 1], "c": [1, 2, 3, 4]}).set_index(["a", "b"])

sweet = df.loc[[1, 1]]
low_sugar = df.loc[[1, 1],:]
savoury = df.loc[([1, 1],), :]

assert_frame_equal(sweet, low_sugar) # these are the same
assert_frame_equal(sweet, savoury) # assertion error, these are not

Issue Description

The documentation for advanced hierarchical indexing https://pandas.pydata.org/docs/user_guide/advanced.html#advanced-indexing-with-hierarchical-index says:

You don’t have to specify all levels of the MultiIndex by passing only the first elements of the tuple. For example, you can use “partial” indexing to get all elements with bar in the first level as follows:

In[43]: df.loc["bar"]
Out[43]: 
               A         B         C
second                              
one     0.895717  0.410835 -1.413681
two     0.805244  0.813850  1.607920

This is a shortcut for the slightly more verbose notation df.loc[('bar',),] (equivalent to df.loc['bar',] in this example).

So my reading of this is that if I provide a non-tuple key, it is desugared using the following pattern rewrite:

df.loc[key] => df.loc[key,] => df.loc[(key, ),] => df.loc[(key, *[slice(None)]*(df.index.nlevels - 1)), slice(None)]

In particular, if my multiindex has two levels, I expect that:

df.loc[key] <=> df.loc[(key, slice(None)), :]

However, if the key is a list-like and it contains repeated labels, then this equivalence does not hold. In particular, the desugared version appears to uniquify the key labels, whereas the sweet version does not. From investigation it looks like the critical step where something goes down a different codepath is if the row indexer is not a tuple. Per desugaring documentation, a singleton row indexer row_key is the same as (row_key, ) and thence (row_key, slice(None)), but it looks like it dispatches down a different route before getting to this stage.

Expected Behavior

Treatment of duplicate keys in label lookups is not (AFAICT) really discussed in the indexing documentation, but I would expect these two approaches to result in the same answer.

Installed Versions

INSTALLED VERSIONS
------------------
commit           : 866a388412067f39e5be9ba75d0fbeff10ae5fd7
python           : 3.10.11.final.0
python-bits      : 64
OS               : Linux
OS-release       : 5.19.0-46-generic
Version          : #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 UTC 2
machine          : x86_64
processor        : x86_64
byteorder        : little
LC_ALL           : None
LANG             : en_GB.UTF-8
LOCALE           : en_GB.UTF-8

pandas           : 2.1.0.dev0+1123.g866a388412
numpy            : 1.24.3
pytz             : 2023.3
dateutil         : 2.8.2
setuptools       : 67.7.2
pip              : 23.1.2
Cython           : 0.29.33
pytest           : 7.3.2
hypothesis       : 6.79.1
sphinx           : 6.2.1
blosc            : None
feather          : None
xlsxwriter       : 3.1.2
lxml.etree       : 4.9.2
html5lib         : 1.1
pymysql          : 1.0.3
psycopg2         : 2.9.3
jinja2           : 3.1.2
IPython          : 8.14.0
pandas_datareader: None
bs4              : 4.12.2
bottleneck       : 1.3.7
brotli           : 
fastparquet      : 2023.4.0
fsspec           : 2023.6.0
gcsfs            : 2023.6.0
matplotlib       : 3.7.1
numba            : 0.57.0
numexpr          : 2.8.4
odfpy            : None
openpyxl         : 3.1.2
pandas_gbq       : None
pyarrow          : 12.0.0
pyreadstat       : 1.2.2
pyxlsb           : 1.0.10
s3fs             : 2023.6.0
scipy            : 1.10.1
snappy           : 
sqlalchemy       : 2.0.16
tables           : 3.8.0
tabulate         : 0.9.0
xarray           : 2023.5.0
xlrd             : 2.0.1
zstandard        : 0.19.0
tzdata           : 2023.3
qtpy             : None
pyqt5            : None

[wence-]

A similar difference occurs when slicing with a strided slice:

df = pd.DataFrame({"a": [1, 1, 2, 2, 3, 4, 4], "b": [0, 1, 2, 3, 4, 5, 6], "c": [1, 2, 3, 4, 5, 6, 7]}).set_index(["a", "b"])

df.loc[slice(None, None, 2), :]
#     c
# a b   
# 1 0  1
# 2 2  3
# 3 4  5
# 4 6  7

df.loc[(slice(None, None, 2),), :]
#     c
# a b   
# 1 0  1
#   1  2
# 3 4  5

# And without a multiindex
df = df.reset_index().set_index("a")
df.loc[slice(None, None, 2), :]
#    b  c
# a      
# 1  0  1
# 2  2  3
# 3  4  5
# 4  6  7

So it looks like in the plain index case (as well as the "short-hand" multiindex version) slices with strides find the positional endpoints and then stride the slice, whereas in the desugared multiindex version, slices find the positional endpoints and then stride the unique values.