Proposed resolution:

Modify the header <typeinfo> synopsis in [support.rtti]p1 as follows:

namespace std { 
  class type_info; 
  class type_index;
  template <class T> struct hash;
  template<> struct hash<type_indexconst type_info *> : public std::unary_function<type_indexconst type_info *, size_t> {
    size_t operator()(type_indexconst type_info * indext) const;
  };
  concept_map LessThanComparable<const type_info *> see below
  class bad_cast; 
  class bad_typeid;
}

Add the following new subsection

18.7.1.1 Template specialization hash<const type_info *> [type.info.hash]

size_t operator()(const type_info *x) const;

1. Returns: x->hash_code()

Add the following new subsection

18.7.1.2 type_info concept map [type.info.concepts]

concept_map LessThanComparable<const type_info *> {
  bool operator<(const type_info *x, const type_info *y) { return x->before(*y); }
  bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); }
  bool operator>(const type_info *x, const type_info *y) { return y->before(*x); }
  bool operator>=(const type_info *x, const type_info *y) { return !x->before(*y); }
}

1. Note: provides a well-defined ordering among type_info const pointers, which makes such pointers usable in associative containers (23.4).

Remove section [type.index]

[ 2009-03-31 Peter adds: ]

It is not true, in principle, that std::type_index provides no utility compared to bare std::type_info*.

std::type_index can avoid the lifetime issues with type_info when the DLL that has produced the type_info object is unloaded. A raw type_info* does not, and cannot, provide any protection in this case. A type_index can (if the implementor so chooses) because it can wrap a smart (counted or even cloning) pointer to the type_info data that is needed for name() and before() to work.

Addresses DE 17

DE-17:

The class type_index should be removed; it provides no additional functionality beyond providing appropriate concept maps.