Proposed resolution:

Replace "new" with "::new" in both cases.

This applies to the new expression that is contained in both par12 of [allocator.members] and in par2 (table 32) of [default.con.req]. I think this new expression is wrong, involving unintended side effects.

[allocator.members] contains the following 3 lines:

  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
     void construct(pointer p, const_reference val);
  12 Returns: new((void *) p) T( val)

[default.con.req] in table 32 has the following line:

  a.construct(p,t)   Effect: new((void*)p) T(t)

.... with the prerequisits coming from the preceding two paragraphs, especially from table 31:

  alloc<T>             a     ;// an allocator for T
  alloc<T>::pointer    p     ;// random access iterator
                              // (may be different from T*)
  alloc<T>::reference  r = *p;// T&
  T const&             t     ;

Cause of using "new" but not "::new", any existing "T::operator new" function will hide the global placement new function. When there is no "T::operator new" with adequate signature, every_alloc<T>::construct(..) is ill-formed, and most std::container<T,every_alloc<T>> use it; a workaround would be adding placement new and delete functions with adequate signature and semantic to class T, but class T might come from another party. Maybe even worse is the case when T has placement new and delete functions with adequate signature but with "unknown" semantic: I dont like to speculate about it, but whoever implements any_container<T,any_alloc> and wants to use construct(..) probably must think about it.