Undo Framework Design (Revert the changes in the collection)
Edge cases

This fails to handle several edge-cases:


Undoing a remove action multiple times results in that item being added back multiple times.
Undoing an update action after other items have been inserted at a lower index causes the wrong items to be replaced.
Lists can contain duplicate items, but only the last operation for each distinct item is remembered.
Updating an item leaves the add-operation for the original item, but attempting to undo that add-operation fails unless the update action has first been undone.


As the last point demonstrates, you can't just undo an action without undoing all actions that followed it first. If you do want to support something like that, you'll have to clearly define the requirements and figure out what the desired behavior is for a variety of edge-cases. You'll also want to make this information available to those that will use this code (documentation, see below).

Implementation notes


Hiding methods with new is rarely a good idea: (changeList as IList&lt;string&gt;).Add("untracked item"); probably does not do what you want it to do. In this case, don't inherit from List&lt;T&gt;: implement the necessary interfaces manually, and use an internal List&lt;T&gt; for the actual storage.
List&lt;T&gt; (and IList&lt;T&gt;) provides some other methods (Insert, [int index] and Clear) that are not being 'intercepted', resulting in untracked changes.
Undoing an action is complicated. Why should the caller need to know whether to use NewValue or OriginalValue? That makes it difficult to use correctly. Why does the caller need to pass in any arguments at all? Why use a wrapper class if you can just create a closure with all the necessary state?
Try to use clear, descriptive names. UndoableAction and Undo are much clearer than ActionWrapper and Action, and Replace is a more accurate description of what the Update method does.
Those RevertAdd/Remove/Update methods don't seem to be intended for public use, so don't make them public. They only clutter the interface of your class.
Those ActionWrapper properties should probably not be public either, but if they have to be, then at least make them read-only. You don't want other code to be able to mess with the internals of your change-tracking/undo system. The same goes for that ActionMap property: it should only be exposed as a get-only IReadOnlyDictionary.
Documentation is entirely absent. That makes it even more difficult to tell how this class is meant to be used (or even what its exact purpose is), and various details such as Remove only removing the first matching item are left to the caller to figure out. It also makes it difficult for others to distinguish between intended and incorrect behavior.


Alternative design

I'd go for a different design, one that doesn't expose internal details, doesn't allow for out-of-order undoing (which means less edge-cases), and that provides a simple interface that's easy to use correctly (note how it's not possible to undo the same action multiple times):

public class ChangeTrackingList&lt;T&gt; // implements IList&lt;T&gt; and/or other interfaces
{
    private List&lt;T&gt; _items = new List&lt;T&gt;();
    private Stack&lt;Action&gt; _undoActions = new Stack&lt;Action&gt;();

    public bool UndoLastAction()
    {
        if (!_undoActions.Any())
            return false;

        var undoLastAction = _undoActions.Pop();
        undoLastAction();
        return true;
    }

    public void Add(T item)
    {
        _items.Add(item);

        // Ensure that this item gets removed, and not an identical earlier occurrence:
        var index = _items.Count - 1;
        _undoActions.Push(() =&gt; _items.RemoveAt(index));
    }

    ...
}