PasteCommand.  These could also be called Actions or Intents (and I have another name I'll reveal below).

Second, we define a way to map Verbs to ICommands.

class VerbBinding
{
     public ICommand Command { ... };
     public Verb Verb { .... };
}

Any UIElement could define VerbBindings just like they can CommandBindings and InputBindings today.    

Third, we have ways to map input to Verbs. 

class InputToVerbBinding
{
   public InputGesture InputGesture { ... };
   public Verb Verb { ... };
}

These could be defined "globally" in the input system, or scoped to tree elements.

In this design, the View maps basic input like keystrokes and mouse and touch gestures (all InputGestures) either to ICommands directly on the ViewModel or maps them to generic Verbs like Copy and Paste.  Verbs in turn act like input and route through the visual tree until they find a Binding that maps them to a ICommand on the ViewModel.  Imagine we had a VerbBinding which took Verb and an ICommand and called execute on the ICommand whenever the Verb was handled.  So for example, a menu might contain Verb="ApplicationVerbs.Paste" and there would also be a default key binding that would map Ctrl-V to ApplicationVerbs.Paste and the developer might also decide to map TwoFingerTouch to ApplicationVerbs.Paste.  Whenever the menu was hit or the Ctrl-V key was pressed, the PasteVerb would be fired and route just like input until it was handled by a VerbBinding and directed to the ViewModel.   (One nuance is that TextBox and other controls may also handle common Verbs like Paste...but let's set that aside for a moment). 

If you squint at this design, you start to realize that Verbs act just like InputGestures.  And funnily enough if you look in the input system you find we already have precedence for taking one input event and turning it into another one:  we turn Stylus input gestures into Mouse gestures so that applications that are not specifically programmed to handle a Stylus will still work.    Similarly, in the future we will cause dragging a finger across a touch screen fire not only TouchMove but MouseMove gestures so that apps written before Touch was supported will still work (with limitations).  So InputToVerbBinding could just be a way to extend the input system to map one set of InputGestures to another generically.  More abstractly, if we introduce a Touch gesture that means Paste, if the system just adds a global InputToVerbBinding, then any app that handles the Paste Verb will be future proofed.

Hmmm...does that mean Verbs are just InputGestures?  I mentioned I had another name for Verb in mind.  How about "AbstractGesture"? AbstractGesture would just be a peer to KeyGesture and MouseGesture (lousy name though...VerbGesture?).  If Verbs are InputGestures, then we no longer need a special VerbBinding, InputBinding is sufficient.  I also mentioned that there was a nuance that controls need to handle common Verbs.  Well, controls can handle InputGestures and if Verbs are a type of InputGesture...so we're done.  Alternatively and more abstractly, TextBox can be thought of as a ViewModel for a string property on your model...but I don't blame you if your head starts spinning now.

In the final design, we get rid of RoutedCommand and add a new sub-class of InputGesture called Verb.  CommandBinding goes away in favor of reusing InputBinding.  The InputGesture property of RoutedCommand is replaced by a new input extensibility that allows us to map one InputGesture to another.  ApplicationCommands, EditingCommands etc. become collections of common verbs and their default mappings from other InputGestures.  I'd probably invent a new thing like the InputToVerbBinding I mentioned, but I don't have a good name for it.

Feedback appreciated.