After thinking about this more while writing up the description, and talking with @dcausse today, I think I'm going to close this ticket for now. If this shows up more often and more annoyingly than it seems to me that it will, someone can re-open the ticket.

Concerns, Ideas, & Notes:

• For shorter queries, creating the пщ vs Go/Golang problem is trading one edge case another, more confusing edge case. This is the biggest factor in my opinion, and the one that seemed to be most convincing to others.
• In general, for longer queries it's likely that there will be fewer options that share a prefix to push the exact match out of top place.
• Incidental mitigations:
  • Related to T411933, we may add second-try matches into the function called from the go feature, which means that hitting return could take you to the normalized exact match page (like it already does for, say, Mõscow and "Moscow" on ruwiki).
  • We may look at re-weighting redirects anyway, which might fix many instances of not having the exact match at the top.
• Ideas to remember:
  • We could implement a minimum length for exact-match reranking and ignore 1- and 2-letter queries.
  • We could have a preferred mapping direction, such that Latin→Cyrillic transformations are eligible for exact-match reranking on ruwiki while Cyrillic→Latin are not (since Cyrillic is the native script of the wiki). If we enable Ru/Qwerty second-try on English Wikipedia, the preferred direction would go the other way.
  • We could try to score the original and mapped queries to decide which are "good". I have some gibberish detection patterns I use elsewhere that could possibly tell that ьщысщц is less word-like than moscow—though they probably couldn't choose between Genby and Путин (a well known case where the wrong keyboard version of something is actually reasonably word-like).
  • If we decide we should look at this again more closely, we could do some data mining to get a sense of how often these wrong-keyboard exact matches were skipped and look at the kind of queries that generate them.
• We're already calling this "second-try" (which sounds nicer than "last-ditch")... we're trying to recover from a user error; we'll never get them all.