Proposed resolution:

This wording is relative to N4659.

1. Add a paragraph to [namespace.std], before p2:

   -1- The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.(footnote: […])

   -?- The behavior of a C++ program is undefined if it declares an explicit or partial specialization of any standard library variable template, except where explicitly permitted by the specification of that variable template.

   -2- The behavior of a C++ program is undefined if it declares […]

[ 2017-06-14, Moved to Tentatively Ready after 6 positive votes on c++std-lib ]

There's currently no rule against specializing the various _v convenience variable templates outside of <type_traits>.

There should be; foo_v<T> should be always equal to foo<T>::value. The correct way to influence, say, is_placeholder_v<T> should be to specialize is_placeholder, not is_placeholder_v. Otherwise, the editorial changes to use the _v form to the specification would no longer be editorial but have normative impact.

Adding a global prohibition in [namespace.std] seems preferable to adding individual prohibitions to each affected template; the PR below carves out an exception for variable templates that are intended to be specialized by users. As far as I know there are no such templates in the current WP, but the Ranges TS does use them.