Proposed resolution:

This wording is relative to N4878.

1. Modify [stacktrace.syn], header <stacktrace> synopsis, as indicated:

   namespace std {
     // [stacktrace.entry], class stacktrace_entry
     class stacktrace_entry;
   
     // [stacktrace.basic], class template basic_stacktrace
     template<class Allocator>
     class basic_stacktrace;
   
     // basic_stacktrace typedef names
     using stacktrace = basic_stacktrace<allocator<stacktrace_entry>>;
   
     […]
   
     // [stacktrace.basic.hash], hash support
     template<class T> struct hash;
     template<> struct hash<stacktrace_entry>;
     template<class Allocator> struct hash<basic_stacktrace<Allocator>>;
   
     namespace pmr {
       using stacktrace = std::basic_stacktrace<polymorphic_allocator<stacktrace_entry>>;
     }
   }
   

[ 2021-10-23 Resolved by the adoption of P2301R1 at the October 2021 plenary. Status changed: Tentatively Resolved → Resolved. ]

[ 2021-03-12; Reflector poll ]

Set priority to 3 and status to LEWG following reflector poll.

P2301 would resolve this.

std::stacktrace is almost std::vector<stacktrace_entry>. This makes it an obvious candidate to define an alias for std::polymorphic_allocator.

Daniel:

It should be pointed out that a theoretically possible (additional) template alias

namespace pmr {
  template<class T>
    using basic_stacktrace = std::basic_stacktrace<polymorphic_allocator<T>>;
}

— albeit it would seem a natural choice when comparing with existing pmr typedef additions — would not provide any advantage for the user, because template parameter T would essentially need to be constrained to be equal to std::stacktrace_entry.