Rationale:

The facets in Table 52 are an unbounded set. Locales should not be required to contain an infinite number of facets.

It's not necessary to talk about which values of InputIterator and OutputIterator must be supported. Table 51 already contains a complete list of the ones we need.

Proposed resolution:

In [locale.category], paragraph 3, change "that is a member of a standard category" to "shown in Table 51".

It's unclear whether 22.1.1.1.1, p3 says that has_facet<Facet>(loc) returns true for any Facet from Table 51 or whether it includes Table 52 as well:

For any locale loc either constructed, or returned by locale::classic(), and any facet Facet that is a member of a standard category, has_facet<Facet>(loc) is true. Each locale member function which takes a locale::category argument operates on the corresponding set of facets.

It seems that it comes down to which facets are considered to be members of a standard category. Intuitively, I would classify all the facets in Table 52 as members of their respective standard categories, but there are an unbounded set of them...

The paragraph implies that, for instance, has_facet<num_put<C, OutputIterator> >(loc) must always return true. I don't think that's possible. If it were, then use_facet<num_put<C, OutputIterator> >(loc) would have to return a reference to a distinct object for each valid specialization of num_put<C, OutputIteratory>, which is clearly impossible.

On the other hand, if none of the facets in Table 52 is a member of a standard category then none of the locale member functions that operate on entire categories of facets will work properly.

It seems that what p3 should mention that it's required (permitted?) to hold only for specializations of Facet from Table 52 on C from the set { char, wchar_t }, and InputIterator and OutputIterator from the set of { {i,o}streambuf_iterator<{char,wchar_t}> }.