Well, the current official documentation,
PlexPlug-inFramework.pdf, details the usage of
A boolean specifying whether the container should be added to the client’s history
stack. For example, if Container B in the sequence A => B => C had no_cache
set to True, navigating back from C would take the user directly to A.
A boolean specifying whether the container should replace the previous container
in the client’s history stack. For example, if Container C in the sequence A => B
=> C had replace_parent set to True, navigating back from C would take the user
directly to A.
Those attributes are very useful in theory, for example when launching a menu item which returns the main/root menu instance again, to emulate a "redirect" to the root menu.
(The framework doesn't seem to allow us to modify or make HTTPRequests like a HTTPResponseRedirect inside the sandboxed URL handling of the plugin ourselves, which is a separate issue.)
In PlexWeb neither of those attributes seem to have any effect.
This results in a user-confusing browser history state, where he presses the back button and triggers any action which was done before, including the root-root menu transition.
In the Sub-Zero plugin, for example, there is a generic library browser built in, with the option to refresh or force-refresh a single item. After the user presses the refresh button, the plugin redirects to the root menu and displays a status message. In this case a
no_history handling on the last ObjectContainer with said button to skip adding the action itself to the browser history, would be very useful.