This looks good to me. While looking at the tests and also #27637, I did wonder whether you really want the output to be StringDType in something like replace when what you started with was a U array. But I think it probably is just good to moving towards StringDType by default.

Looks fine to me. I think there might be a whole in the logic for out=, but I am not sure it is worth digging deeper (as opposed to a follow-up, maybe when a bug is reported).

I would love to find a better story for this type of thing... The one story that I could potentially see is to make something like an abstract (doesn't need to be an actual thing could just be a tuple as in isinstance, but conceptually):

class StringOrUnicodeDType:

so that we could just add one promoter, but the promoter would be need to programmatically decide whether the result should be unicode or string.
(Similar to the "this dtype must occur", style of logic. But these ufuncs that include ints show that just a list of dtypes is not super helpful a such)

(Sorry, the changes look good to me, but I am not sure I am in the right state of mind for any inspiration, although I do suspect the tuple idea is about as good as it gets. Together with allowing a promoter to say "do not apply" it would go very far -- if we allow that, a promoter could even register everything, it would just not be friendly)

EDIT: I forgot to say thanks :), this is tricky stuff and looks good, just unfortunately verbose. And verbose isn't fully unintentionally, but it would be good to improve it.