Actually, that was removed by intention on the basis of discussions some time ago. How can you be sure that the user does not want to enter "wikida" but "Wikidata"? Although I prefer the ease of using auto-completing, it can be dangerous to make assumptions here.
For using the method of auto-completing we had, the suggestion system should be flawless which is not the case and we cannot influence the system directly; even more when a Wikibase instance should link to non-MediaWiki sites.
As to MediaWiki, for example: Try adding a German site link to "Allegro". You get "Allegro Film" as first suggestion although there is an article "Allegro". Unless such edge cases are not filtered out specifically, the user would need to erase the auto-completed " Film" before saving. With having to consider a big pool of languages, there are most likely problems and edge cases we are not even aware of.
In addition to just presenting suggestions, auto-completing adds to the assumption that only the suggested values are valid values.
If we want to have auto-completion again, I would favour a more unobtrusive implementation, like Google does with instant search where the user needs to dedicatedly press the right arrow key to auto-complete. But is saving one keypress worth the effort at the moment? Auto-completion is quite a technical burden and had flaws in the previous implementation. It would be no big deal to re-implement the old behaviour (we have jQuery.autocompletestring), but I would refrain from that.

(In reply to Henning from comment #1)

How can you be sure that the user does not want to enter "wikida"

If the user knows "wikida" is in the list, he can type "wikida" and nothing bad will happen, with or without auto-completion.

If "wikida" is not in the list, what's more common?

1. A user typing "wikida", hitting enter and expecting to get an error message, which is currently the case and what I find useless and confusing ("The specified article could not be found on the corresponding site. Details: The external client site did not provide page information").

2. A user typing "wikida", hitting enter and expecting the first match (which is "Wikidata") to be saved?

I know that there is an argument for _not_ having auto-completion, but I consider the arguments for having it much stronger.

You get "Allegro Film" as first suggestion although there is an article
"Allegro".

Which is an issue I would happily fix.

auto-completing adds to the assumption that only the suggested values
are valid values.

Which is always the case.

But is saving one keypress worth the effort

It's not only about saving key presses, it's about what the users expect.

So, which authority is going to make a decision, finally?

I can identify three options:

• no auto-completion (current state)
• "hard" auto-completion (old state)

Auto-completed suffix characters are inserted as selected text into the input box, tabbing/clicking out of the box involves automatic auto-completion. In order to prevent auto-completion, the "delete" key needs to be pressed.

• "soft" auto-completion

Auto-completed characters are underlayed with a light colour but are not actual text in the input box. Tabbing/clicking out of the input box does not auto-complete, only dedicatedly pressing the "right arrow" key does.

What is your preferred option, @Snaterlicious?
It seems to me the current state is fine with people and it feels right to me. Not dead set on this though.

I still prefer the "hard" option for most suggesters we have.

Please note that such an auto-completion can be a pain in cases where free-text values (values not in the suggesters list) are valid. This suggests this needs to be an option or implemented in sub-classes. But we currently don't have such "anything goes" suggesters, as far as I'm aware of. Only values in the suggesters list are valid inputs. If I start typing "wikid" and hit enter "wikidata" I expect "Wikidata" to be saved, not an error message.

As said the "Allegro" issue mentioned above should be fixed.

The pros and cons were discussed in older comments already... I am reluctant to retrigger the discussion.

It boils down to the question is whether there should be a "selector" or a "suggester". (While it makes sense for a "selector" to use "hard" auto-completion, a "suggester" should not use "hard" auto-completion as that implies only the suggested values being valid.)

On the one hand, I would agree to what should be applied to the page input box, technically, is a "selector". However, since the results are aggregated in an external scope, there is no reliance on the results delivered being accurate. Furthermore, results are delivered with a delay and it cannot be relied on results being supplied at all while the nature of a "selector" is to only allow selecting form a supplied set of values.

As I stated before, I think "soft" auto-completion might be nice to have but, eventually, there is not enough (if any at all) benefit justifying the effort.

Bottom line: Our implementation is torn between the fact that the applied widget should be a "selector" but, due to the technical circumstances explained above, a "suggester" seems to be more applicable. I tend to leaving it at the current state as that resolves in less implications. (This is a practical suggestion.)
And in the end, a user already waiting for the API request should be fine with having to hit the "down" arrow in order to apply the suggested value.

So to wrap this up, the reason why the page suggester is a suggester and not a selector is that the front end API request ...
http://en.wikipedia.org/w/api.php?action=opensearch&search=Kittens
... is different from the back end API request ...
http://en.wikipedia.org/w/api.php?action=query&prop=info&redirects=1&converttitles=1&format=json&titles=Kittens
... and they may return slightly different results. With "different" having two meanings:

1. Missing results, in my humble opinion, qualify as a bug.
2. If different order (e.g. ".net" is not the 1st if you search for ".NET") qualifies as a bug could probably be disputed.

I understand that both is nothing we can easily fix, if at all.

I still think the described feature is important in most other selectors, but they already have it, right?