Proposed resolution:

1. In [istream.formatted.arithmetic]/2 change the current as-if code fragment

   typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
   iostate err = 0;
   long lval;
   use_facet<numget>(loc).get(*this, 0, *this, err, lval );
   if (err == 0) {
     && if (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
         err = ios_base::failbit;
     else
       val = static_cast<short>(lval);
   }
   setstate(err);
   

   Similarily in [istream.formatted.arithmetic]/3 change the current as-if fragment

   typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
   iostate err = 0;
   long lval;
   use_facet<numget>(loc).get(*this, 0, *this, err, lval );
   if (err == 0) {
     && if (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
         err = ios_base::failbit;
     else
       val = static_cast<int>(lval);
   }
   setstate(err);
   

2. ---

To the more drastic changes of [istream.formatted.arithmetic] in the current draft N2134 belong the explicit description of the extraction of the types short and int in terms of as-if code fragments.

1. The corresponding as-if extractions in paragraph 2 and 3 will never result in a change of the operator>> argument val, because the contents of the local variable lval is in no case written into val. Furtheron both fragments need a currently missing parentheses in the beginning of the if-statement to be valid C++.
2. I would like to ask whether the omission of a similar explicit extraction of unsigned short and unsigned int in terms of long - compared to their corresponding new insertions, as described in [ostream.inserters.arithmetic], is a deliberate decision or an oversight.