Probably needs to be retested after https://gerrit.wikimedia.org/r/83655 is deployed

Can't reproduce, tried with both Firefox 24.0 and with Chromium 29.0.1547.57. Although I didn't specifically test having the *home* wiki as itwiktionary.

If you can capture the HTTP request and response headers for the following (obscure the values of any cookies with names ending in "Token" or "Session", but please indicate which were the same across requests), that would be helpful:

• The POST of the login form on itwiktionary, and all the subsequent redirects
• Any calls to Special:CentralAutoLogin on the HTML page from the previous
• The request on ruwiktionary after having logged in on itwiktionary
• Any calls to Special:CentralAutoLogin on the HTML page from the previous (there shouldn't be any, though)

To capture the headers, the information in http://productforums.google.com/forum/#!topic/chrome/1u7DQv-ag_4 may be helpful; note there will be multiple HTTP_TRANSACTION_SEND_REQUEST_HEADERS and HTTP_TRANSACTION_READ_RESPONSE_HEADERS blocks in one URL_REQUEST in the case of redirects.

I reproduced again with steps as above, with [[Special:CentralAuth/Bug_54119_test]]; I stopped at step 4 because that's what you requested. There is no need to obfuscate headers because it's a throw-away account.
I forgot to follow the instructions closely on it.wikt login, so I only have HAR files for that and step 0. Note that in step 0 I had to manually login on it.source (but not en.source) to create the account.
Attachments follow.

Created attachment 13299
Step 1 (account creation) HARs

Attached:

Created attachment 13300
Special:CentralAutoLogin calls 1

Attached:

Created attachment 13301
Special:CentralAutoLogin calls 2

Attached:

Created attachment 13302
Special:CentralAutoLogin calls step 3

Attached:

Created attachment 13303
Special:CentralAutoLogin calls step 4

Attached:

Created attachment 13304
Step 3-4 HARs and URL_REQUEST details

Attached:

Created attachment 13305
Step 4 net-internals export

Attached:

So, to expand on the comment above, in the first attempted auto-login after account creation there wasn't any call to login code or special pages that I could see; in step 4 there were some but apparently not successful.

That didn't really help. Looking at the connections to ruwiktionary in attachment 13304, I see all the correct cookies were sent so you *should* have been logged in.

..... Ugh. Have you tried it with a username that isn't caught by ruwiktionary's TitleBlacklist rule ".*\d{5,}.* <newaccountonly> # 5+ digits running", or any of their other very restrictive blacklist rules? Or can you reproduce it on any wiki other than ruwiktionary (or one with the same sort of rules)?

(In reply to comment #12)

That didn't really help. Looking at the connections to ruwiktionary in
attachment 13304 [details], I see all the correct cookies were sent so you
*should* have
been logged in.

..... Ugh. Have you tried it with a username that isn't caught by
ruwiktionary's TitleBlacklist rule ".*\d{5,}.* <newaccountonly> # 5+ digits
running", or any of their other very restrictive blacklist rules? Or can you
reproduce it on any wiki other than ruwiktionary (or one with the same sort
of
rules)?

Sigh. I chose a random wiki to avoid bias, I should have used one of those super-small languages as I usually do. However, why did I have to manually login on the first of (it|en).source to create the account on step 1? I'll try to reproduce again elsewhere...

(In reply to comment #13)

However, why did I have to manually login on the first of (it|en).source to
create the account on step 1?

Possibly bug 54292?

(In reply to comment #14)

(In reply to comment #13)

However, why did I have to manually login on the first of (it|en).source to
create the account on step 1?

Possibly bug 54292?

Indeed that bug might be the correct formulation of what I tried to report here. I'll check better later.

I'm going to mark this RESOLVED INVALID, per comment 12 that the main complaint here an issue with one wiki's TitleBlacklist configuration (and the followup complaint in comment 13 seems covered by bug 54292). Feel free to reopen if it can be demonstrated that that's not the case.

(In reply to comment #16)

Feel free to reopen if
it
can be demonstrated that that's not the case.

Yes, I planned to retest this after the fix for bug 54292 is deployed.