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