Proposed resolution:

[Drafting note: Because an upcoming paper provides iterator-pair constructors for other container adaptors, the wording below adds the restriction to [container.adaptors.general] so that it also covers the constructors that will be added by that paper. — end drafting note]

This wording is relative to N4878.

1. Add the following paragraph to [container.adaptors.general] after p3:

   -?- A constructor template of a container adaptor shall not participate in overload resolution if it has an InputIterator template parameter and a type that does not qualify as an input iterator is deduced for that parameter.

   -4- A deduction guide for a container adaptor shall not participate in overload resolution if any of the following are true:

   1. (4.1) — It has an InputIterator template parameter and a type that does not qualify as an input iterator is deduced for that parameter.

   2. […]

[ 2021-06-07 Approved at June 2021 virtual plenary. Status changed: Voting → WP. ]

[ 2021-02-26; LWG telecon ]

Set status to Tentatively Ready after discussion and poll.

There is nothing in [priority.queue] or more generally [container.adaptors] saying that InputIterator in the following constructor templates has to be an input iterator.

template<class InputIterator>
    priority_queue(InputIterator first, InputIterator last, const Compare& x,
                    const Container&);
template<class InputIterator>
    priority_queue(InputIterator first, InputIterator last,
                    const Compare& x = Compare(), Container&& = Container());

The second constructor template above therefore accepts

std::priority_queue<int> x = {1, 2};

to produce a priority_queue that contains a single element 2. This behavior seems extremely questionable.