[Moved to DR at the May, 2015 meeting.]

Proposed resolution (November, 2014):

Change 7.6.2.2 [expr.unary.op] paragraph 10 as follows:

The operand of ~ shall have integral or unscoped enumeration type; the result is the one's complement of its operand. Integral promotions are performed. The type of the result is the type of the promoted operand. There is an ambiguity in the unary-expression ~X(), where X is in the grammar when ~ is followed by a class-name or decltype-specifier. The ambiguity is resolved in favor of by treating ~ as a the unary complement operator rather than treating ~X as referring to as the start of an unqualified-id naming a destructor. [Note: Because the grammar does not permit an operator to follow the ., ->, or :: tokens, a ~ followed by a class-name or decltype-specifier in a member access expression or qualified-id is unambiguously parsed as a destructor name. —end note]

There is language in 7.6.2.2 [expr.unary.op] paragraph 10 to disambiguate destructor references from references to operator~:

There is an ambiguity in the unary-expression ~X(), where X is a class-name or decltype-specifier. The ambiguity is resolved in favor of treating ~ as a unary complement rather than treating ~X as referring to a destructor.

However, it is not clear whether this is intended to apply to an example like,

  struct X {
    X(int);
    operator int();
    void foo() {
      ~X(0);
    }
  };

where the form of reference has an apparent argument.