One question to ask ourselves here is whether we want to also implement loops for mixed dtypes like unicode + bytes, unicode + object, bytes + object, unicode + void and bytes + void.

I don't think the ufunc fastpath has anything to offer once object dtype is used. And I don't know how common it is to add string_ and bytes_, so my first instinct would be to keep this as simple as possible.

Here's another run of the benchmarks.

| Change   | Before [64fc516a] <main>   | After [6b970817] <string-ufuncs-add>   |   Ratio | Benchmark (Parameter)                               |
|----------|----------------------------|----------------------------------------|---------|-----------------------------------------------------|
| -        | 18.0±0.3μs                 | 3.04±0.05μs                            |    0.17 | bench_core.NumPyChar.time_add_small_list_big_string |
| -        | 3.29±0.01ms                | 9.77±0.5μs                             |    0    | bench_core.NumPyChar.time_add_big_list_small_string |

And I don't know how common it is to add string_ and bytes_, so my first instinct would be to keep this as simple as possible.

I agree, we shouldn't assume the encoding of bytes_ data, which you would need to do I think.

This appears to be ready to merge. Are there any more review comments for me to address?

It needs a release note. Look in doc/release/upcoming_changes/ for examples.

@charris Added a minimal release note. Should it be more comprehensive than that?

Thanks @lysnikolaou!