BUG: String series cat produces NaNs when left operand has a custom index

[brandon-b-miller]

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

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

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Code Sample, a copy-pastable example

import pandas as pd
print(pd.__version__)

x = pd.Series(['a','b','c','d','e'])
x.index = ['1', '2', '3', '4', '5']
pd_others = pd.Series(['f','g','h','i','j'])

print(x.str.cat(others=pd_others))

1.1.0.dev0+1690.g70d7c04ff
1    NaN
2    NaN
3    NaN
4    NaN
5    NaN
dtype: object

Problem description

Possibly related to #33425. The trigger for this bug seems to be the custom index. I get the correct answer if the line where x.index is set is removed.

Expected Output

1.1.0.dev0+1690.g70d7c04ff
0    af
1    bg
2    ch
3    di
4    ej
dtype: object

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 70d7c04
python : 3.8.3.final.0
python-bits : 64
OS : Linux
OS-release : 4.15.0-76-generic
Version : #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.1.0.dev0+1690.g70d7c04ff
numpy : 1.18.1
pytz : 2020.1
dateutil : 2.8.1
pip : 20.0.2
setuptools : 46.4.0.post20200518
Cython : 0.29.17
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : None
pandas_datareader: None
bs4 : None
bottleneck : None
fastparquet : None
gcsfs : None
matplotlib : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pytables : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : None

[TomAugspurger]

I think that's deliberate. .str.cat aligns before catting.

[brandon-b-miller]

Thanks for the clarification @TomAugspurger it indeed works if both operands have the same index. This looks to be an issue on our side!