I've done some playing around... not quite there yet, but I think much closer.

First, I assume the 'freeze' on Mac is not a hard freeze, but where the text window is not responding to events, but if you switch to another app and back, it works again?

Second, right now (assuming I've got the latest), if you click on the listbox it goes away immediately, due to it being included in HIDE_SEQUENCES (meaning ButtonPress generates <<autocompletewindow-hide>> which calls the routine to hide the autocomplete window. Which obscures any double click event etc. 

Third, and I think this is the key to this, is that all of the event_add, event_delete, bind, and unbind are not calling Tkinter routines directly, but are going through the multicall module (which allows an event to fire more than one binding). When we call hide_window, we're doing several event_delete and unbind  calls in multicall to undo the bindings we had set up before. Which should leave us back where we started, with the text widget bindings still firing when events come in.

So then is it an issue of the events not coming in (indicating a bug in Tkinter or how we're calling it), or multicall not correctly dispatching to the text widget?

Stick a print() call in multicall.py:_ComplexBinder:__create_handler:handler and you'll see the events are being generated by Tk, but multicall isn't dispatching them.

When I get a chance again, I can see about digging into multicall to verify if it is doing something wrong.

I'll also raise a meta-issue, and that is that using a multicall-like wrapper approach may not necessarily be the best approach to doing the multiple dispatch. Adding a new (Tk widget) class to the text widget (via the 'bindtags' command) and then attaching bindings to that class would I suspect be simpler.

And finally, one simplification for the autocomplete window class... the listbox generates a <<ListboxSelect>> virtual event every time its selection changes, so you don't need to bind against all the clicks, arrow keys, etc.