Bug 123316 [Undo] - API BEHAVIOR - should always place a successfully undone/redone op on the redo/undo history
bundles/org.eclipse.core.commands/src/org/eclipse/core/commands/operations/IOperationHistory.java
* Once operations are added to the history, the methods
 * {@link #canRedo(IUndoContext)} and {@link #canUndo(IUndoContext)} are used to
 * determine whether there is an operation available for undo and redo in a
 * given undo context. The context-based protocol implies that there is only one
 * operation that can be undone or redone at a given time in a given context.
 * This is typical of a linear undo model, when only the most recently executed
 * operation is available for undo. When this protocol is used, a linear model
 * is enforced by the history.
 * </p>
 * <p>
 * It is up to clients to determine how to maintain a history that is invalid or
 * stale. For example, when the most recent operation for a context cannot be
 * performed, clients may wish to dispose the history for that context.
 * </p>
 * <p>
 * Additional protocol allows direct undo and redo of a specified operation,
 * regardless of its position in the history. When a more flexible undo model is
 * supported, these methods can be implemented to undo and redo directly
 * specified operations. If an implementer of IOperationHistory does not allow
 * direct undo and redo, these methods can return a status indicating that it is
 * not allowed.
 * </p>
 * <p>
 * Listeners ({@link IOperationHistoryListener}) can listen for notifications
 * about changes in the history (operations added or removed), and for
 * notification before and after any operation is executed, undone or redone.
 * Notification of operation execution only occurs when clients direct the
 * history to execute the operation. If the operation is added after it is
 * executed, there can be no notification of its execution.
 * </p>