Additional notes (May, 2009):

There are other examples that exhibit the same problem. For example, _N2960_.14.6.8 [temp.concept.map] paragraph 7 has this example:

    concept Stack<typename X> {
      typename value_type;
      value_type& top(X&);
      // ...
    }

    template<typename T> struct dynarray {
      T& top();
    };

    template<> struct dynarray<bool> {
      bool top();
    };

    template<typename T>
    concept_map Stack<dynarray<T>> {
      typedef T value_type;
      T& top(dynarray<T>& x) { return x.top(); }
    }

dynarray needs to be constrained. Similarly, in _N2914_.14.10.2.2 [concept.map.assoc] paragraph 3, in the example

    concept Allocator<typename Alloc> {
      template<class T> class rebind_type;
    }

    template<typename T>
    class my_allocator {
      template<typename U> class rebind_type;
    };

    template<typename T>
    concept_map Allocator<my_allocator<T>> {
      template<class U> using rebind_type = my_allocator<T>::rebind_type;
    }

my_allocator must be constrained. (Note also the missing template argument in the target of the template alias declaration.)

The example in _N2914_.14.10.3.2 [concept.refine.maps] paragraph 3 reads:

    concept C<typename T> { }
    concept D<typename T, typename U> : C<T> { }
    template<typename T> struct A { };
    template<typename T> concept_map D<A<T>, T> { }
    ...

Since all concept maps templates are constrained templates, we know that we're in a constrained context at the point of the concept_map keyword. Then the first argument to D is A<T>, and A is an unconstrained template, so this is ill-formed by _N2914_.14.11 [temp.constrained] paragraph 5:

Within a constrained context, a program shall not require a template specialization of an unconstrained template for which the template arguments of the specialization depend on a template parameter.

Suggestion: make A a constrained template, e.g.,

    template<std::ObjectType T> struct A { };