Systematizing back navigation

[Po Lu]

There is presently a bewildering set of actions taken in response to an
XF86Back key press.  In most buffers, it is equivalent to typing C-x
<left>, switching to the buffer previously displayed in the current
window.  In Help buffers, it navigates to the last Help notice
displayed, and in Info buffers, it navigates to the last node displayed.

Such behavior is confusing because XF86Back cannot be relied on to
restore an earlier state of affairs, be that a previous window
configuration, Info node or current buffer.  To give an example, if the
Info directory is opened, then the node "(elisp)Numeric Conversions",
the scratch buffer, and the Info buffer once more, XF86Back will return
to the Info directory instead of *scratch*.  If XF86Back is pressed
thereafter, Info will print a message to the effect that there is no
previous node in the Info buffer's history without restoring any earlier
window configuration.

Moreover, restoring merely the last buffer to have been selected does
not suffice at times: when I press Back after typing "F" in a Gnus
Article buffer displays a message buffer occupying the whole frame, I am
brought to the Summary buffer, while it is the previous window
configuration incorporating both the Summary and Article buffers that
should be restored in this case.

The object of such keys as XF86Back and its Android analogs is to undo
the effects of the last navigation: a call to display-buffer, switching
to a different window, clicking on a link in an Info buffer, and the
like.  In the first instance, this calls for a unified undo system which
preserves changes to the window configuration, that they might be
reverted when Back is pressed.

As this cannot account for forms of navigation that spare the window
configuration, Info and Help buffers must also make a note of new nodes
visited within this undo system and supply means by which these
alterations can be undone.

There are two shortcomings to this I can't yet address.  If window
configurations are saved, then the selected window is also accounted a
navigation operation and is subject to change when Back is pressed.  Not
only is this unwanted, it also impedes addressing the second
shortcoming, which is that it ought to be possible for the effect of
Back to be limited to a single window, such as by restoring the selected
buffer of that single window rather than that of the window whose
selected buffer is the last to have changed.

Thus instead of implementing and installing a prototype of this at a
venture, I want to ask everyone else's advice, and also for ideas as
regards when and whether this Back mechanism should act as described in
the last paragraph.

TIA.