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