Thanks for the mention of select2. It looks interesting (and visually much more pleasant), but I'll have to have a closer look at it.
The attached patch introduces a new flag to AutoCompleteSettings, called ignoreBordersWhenPositioning. For backward compatibility it is set to true. When set to false, it includes clientLeft and clientTop in position computations. This computes the position of the input field correctly in IE9+, Firefox 16 and Chrome 22. In IE8 (and, presumably, earlier) it does not: the offsetLeft and offsetTop properties of the input field seem to already contain the borders of the input field's parent element.
What's the preferred Wicket approach in these situations? Should I try to detect the browser and avoid including the borders even though the user asked to include them? Or should we expect the user to set the ignoreBordersWhenPositioning flag according to the browser vendor and version? I will note that the former might still not yield the expected results, because I don't fully understand the IE bug.