>
> ‘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