Ah, just saw Stefan's reply on the mailing list archive (I'm not subscribed
to emacs-devel anymore).  Yes, I think you're right that I was confusing
current-buffer and selected-window.
I'm still a bit curious about the expected semantics of current-buffer, in
particular which built-in commands should I expect to cause c-b to change
asynchronously, in case that's easy to explain.

Cheers,
-a


On Tue, Oct 4, 2016 at 8:45 AM Ami Fischman <ami@fischman.org> wrote:

> ‘describe-key’ is based on ‘with-temp-buffer-window’ which tries very
> hard to restore the current buffer after doing its work.  So what you
> see here is not a stale value but one that has been correctly preserved.
>
>
> I'm sorry but I don't understand your statement.  Should there not be an
> expectation that (current-buffer)'s return value does not change between
> the second and third call in my original snippet?
> Put another way, under what circumstances should one expect
> current-buffer's return value to be stable in user-written elisp?
> Put a third way, what about describe-keys documentation should lead an
> elisp author to understand that current-buffer will not reflect its effect
> until after a [run-at-time 0]?
> (sorry for the barrage of questions; I feel there's a fundamental
> something I'm missing in play here and trying to see if you know what it is
> :))
>
> Please tell us what you want to accomplish.  Then we might be able to
> tell you how to do that.
>
>
> My original goal was to resolve a bug in the interaction between two
> add-on libraries (see the link in my original email).  That bug has been
> fixed by replacing the uses of current-buffer with window-buffer so my
> original goal is now moot.  Now my goal is to understand the intended
> semantics of interaction between current-buffer and describe-key (and its
> impl).
>
> Cheers,
> -a
>