I asked that as well on the POSIX/SUS list and Don Cragun responded with:

"If you make the last argument to setlocale() be a pointer to
unallocated memory, implementations would be allowed to set errno to
EFAULT and terminate the process with a core dump even when this section
says "No errors are defined."  An implementation could also set errno to
ENOENT (e.g., if the "B" locale wasn't known) or to EINVAL (e.g., if the
"B" locale existed but the LC_CTYPE portion of the locale was not in the
proper format).  That wording just means that the standard doesn't
require implementations to detect errors like these nor to report
specific error values for different possible errors."

On the subject whether or not returning a null pointer should be
considered he said:

"The standard is silent on this issue.
Why does it make any difference to an application?
If setlocale(LC_CTYPE, "B") returns a null pointer, the LC_CTYPE portion
of the locale was not changed.  If setlocale(LC_CTYPE, "B") does not
return a null pointer, the LC_CTYPE portion of the locale was
successfully changed."

I am just wondering why we want to be quite different from how many
other languages are approaching the issue. Sure enough, we can use a
try: construct, but it kind of defeats the principle of least
astonishment by being different from the rest on this issue.