I had a quick look on this code and submitted small cleanups starting at https://gerrit.wikimedia.org/r/294445

To implement this, we need to store the language of the translation as well. Then we need to figure a way to prioritize matches. We could try to apply some heuristics such as try autonym first, then user and wiki language, then common world languages that are not user specific or which we know already. Alternatively the client could pass an ordered list of preferred languages that we would use.

IMO, we need to think whether the effort and added codebase, proportional bugs really worth it. I am more inclidend to keep it simple and predictable and less intelligent

To me it's not about complexity (just make it as complex as needed and not more) but priority. The existing code is not simple nor predictable, so I tried to simplify it in the patches.

As a user this issue makes the experience less than smooth.

It seems that the current behaviour is already showing expected results (autocompleting the autonym or the name in the language of the current wiki). I illustrated the same example as in the original ticket and the unexpected results (such as "spanyänapük") are not shown as suggestions for either "spa" or "esp":

I tried for other languages, and the result seems consistent (I filled a separate small bug for the way iso codes are autocompleted that I found in the way, T186480 ). Overall, I'd recommend to close this ticket.