>> We have to detect the moment when the window is closed automatically
>> anyway.  At that time we can either kill the buffer or reset
>> `other-window-scroll-buffer’.
>
> I’m still not sure that even using this variable is a wise idea. It might be used
> by a user to configure his things.

By design it's a plain variable and not a user option.

> A simple custom function that will always scroll
> *Completions* window seems like a better choice. You can always scroll
> by buffer name. No need to force the usage of scroll-other-window function.

IIRC the initial intention was to make the *Completions* window the
`next-window' so it would get scrolled automatically by C-M-v.  When
that failed, `other-window-scroll-buffer' was invented to handle the
case where the *Completions* window was not the next window.  I doubt
that a custom function would gain anything in this regard - it would
still have to find the window to scroll and detect when it's no more
needed.

> I meant that if you only kill the buffer (after we used autocomplete) and
> then user will scroll-other-window (for whatever reason) it won’t behave as
> if its value is nil. We’d have to make it nil as well (as you mentioned now).

Why?  If `other-window-scroll-buffer' denotes a dead buffer, it now
should be tantamount to nil.  Or am I missing something?

> If I had an idea where to start I would have sent a patch instead of reporting a bug :-/

I thought you had because you earlier said that

   All of this happens because a window that's chosen for displaying a window
   for completion is created with 'display-buffer', while the window that is
   scrolled with TAB during completion is choosen with a 'other-window'
   ('scroll-other-window') function. And as shown here those windows are not
   always the same.

which gave me the impression that you already did some preliminary
investigative work.