I reproduced this bug on de.wikipedia.org and it.wikipedia.org with default user language in a browser with accept-language:it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4.

This is a severe regression, probably related to AuthManager. The account registration confirmemail messages have "always" been sent in the correct language, even from multilingual wikis as long as one changed the interface language on Special:UserLogin. My archives mostly contain copies from the 2008–2010 period, but I see e.g. https://wiki.documentfoundation.org/Special:Version (1.24.6) still works correctly.

The control flow goes like this:

1. the user is created, AuthManager::setDefaultUserOptions sets the language from the context language (which is probably wrong for account creation by admin, but not a problem here)
2. user data gets saved, which calls User::clearInstanceCache (meaning the next user option read will load from DB)
3. LoginSignupSpecialPage::setSessionUserForCurrentRequest sets $wgLang from the userlang parameter, and if that does not exist, from the user option
4. transaction gets committed
5. the mails are sent via User::sendConfirmationMail which uses $wgLang

So maybe the SELECT for the user option in step 3 misses the update in step 1 due to consistent reads.

That still shouldn't pick up English on dewiki, though. If the language wasn't set, it should be getting the content language for the local wiki.

I wasn't able to reproduce this on my local testing wiki, so I'll probably have to mess with mw1099 or the like to try to figure out what exactly is going on.

Change 320212 had a related patch set uploaded (by Anomie):
LoginSignupSpecialPage: Don't output empty 'uselang'

https://gerrit.wikimedia.org/r/320212

In T146147#2776247, @Anomie wrote:

I wasn't able to reproduce this on my local testing wiki, so I'll probably have to mess with mw1099 or the like to try to figure out what exactly is going on.

It turns out it needs $wgLoginLanguageSelector = true to reproduce it.

Good catch, thanks! I had not thought of keeping that into account.

Wondering if this might also fix any of
T146574: Watchlist emails should be sent in the user's language
T4592: E-mail notifications (enotifs) are not sent in the recipient's user interface language
T29239: Confirmation email is not generated in Arabic
?

In T146147#2777368, @Aklapper wrote:

Wondering if this might also fix any of

No, it won't fix any of those. The bug here is that the account creation form included uselang= (empty string) in the submission, which caused it to set $wgLang and related settings incorrectly for the request-in-progress. None of those bugs appear to have anything to do with the account creation form.

Change 320212 merged by jenkins-bot:
LoginSignupSpecialPage: Don't output empty 'uselang'

https://gerrit.wikimedia.org/r/320212