Additional note (January, 2014):

A similar problem exists for an operator> template:

  struct S;
  template<void (*)(S, S)> struct X {};
  void operator>(S, S);
  X<operator> > x;

Somehow the specification must be written to avoid taking the > token in the operator name as the end of the template argument list for X.

The Standard does not normatively define which > and >> tokens are to be taken as closing a template-argument-list; instead, 13.3 [temp.names] paragraph 3 uses the undefined and imprecise term “non-nested:”

When parsing a template-id, the first non-nested > is taken as the end of the template-argument-list rather than a greater-than operator. Similarly, the first non-nested >> is treated as two consecutive but distinct > tokens, the first of which is taken as the end of the template-argument-list and completes the template-id.

The (non-normative) footnote clarifies that

A > that encloses the type-id of a dynamic_cast, static_cast, reinterpret_cast or const_cast, or which encloses the template-arguments of a subsequent template-id, is considered nested for the purpose of this description.

Aside from the questionable wording of this footnote (e.g., in what sense does a single terminating character “enclose” anything, and is a nested template-id “subsequent?”) and the fact that it is non-normative, it does not provide a complete definition of what “nesting” is intended to mean. For example, is the first > in this putative template-id “nested” or not?

    X<a ? b > c : d>