Ok. I was looking at:

(defun view-echo-area-messages ()
  “View the log of recent echo-area messages: the `*Messages*’ buffer.
The number of messages retained in that buffer is specified by
the variable `message-log-max’.”
  (interactive)
  (with-current-buffer (messages-buffer)
    (goto-char (point-max))
    (let ((win (display-buffer (current-buffer))))
      ;; If the buffer is already displayed, we need to forcibly set
      ;; the window point to scroll to the end of the buffer.
      (set-window-point win (point))
      win)))

and it’s an example of a function which updates the window-buffer but not the
current-buffer. When I look at the C code for set-window-point, it explicitly
restores the current-buffer to the state it was in before the call. So overall,
this function pops messages-buffer up but will activate the post-command-hook
for the buffer that was current before the call.

I’m not sure if this is a bug or not, but it’s definitely an edge case that
catches a lot of packages off guard.

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That was my guess.  The merged commit just forgoes calling that function
>> if things aren’t as expected.  My plan was (and obviously still is) to
>> look into instead ensuring that the expected buffer is current, making
>> it current if necessary.
>
> As alluded to in my other message, maybe we should consider it a bug
> if `post-command-hook` functions get called with (current-buffer)
> different from (window-buffer) and similarly I’d consider it a bug if
> such a function breaks this invariant.
>
> [ Just putting this out there, hoping to influence who you
>   blame at the end of your “look into” 🙂  ]
>
>         Stefan