Rationale:

For extractors, the note is added to make it clear that skipping whitespace follows an "all-or-none" rule.

For inserters, the LWG believes there is no defect; the standard is correct as written.

Proposed resolution:

After [complex.ops] paragraph 14 (operator>>), add a Notes clause:

Notes: This extraction is performed as a series of simpler extractions. Therefore, the skipping of whitespace is specified to be the same for each of the simpler extractions.

The extractor for complex numbers is specified as: 

template<class T, class charT, class traits> 
basic_istream<charT, traits>& 
operator>>(basic_istream<charT, traits>& is, complex<T>& x);
 
Effects: Extracts a complex number x of the form: u, (u), or (u,v), where u is the real part and v is the imaginary part (lib.istream.formatted). 
Requires: The input values be convertible to T. If bad input is encountered, calls is.setstate(ios::failbit) (which may throw ios::failure (lib.iostate.flags). 
Returns: is .

Is it intended that the extractor for complex numbers does not skip whitespace, unlike all other extractors in the standard library do? Shouldn't a sentry be used? 

The inserter for complex numbers is specified as:

template<class T, class charT, class traits> 
basic_ostream<charT, traits>& 
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);

Effects: inserts the complex number x onto the stream o as if it were implemented as follows:

template<class T, class charT, class traits> 
basic_ostream<charT, traits>& 
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) 
{ 
basic_ostringstream<charT, traits> s; 
s.flags(o.flags()); 
s.imbue(o.getloc()); 
s.precision(o.precision()); 
s << '(' << x.real() << "," << x.imag() << ')'; 
return o << s.str(); 
}

Is it intended that the inserter for complex numbers ignores the field width and does not do any padding? If, with the suggested implementation above, the field width were set in the stream then the opening parentheses would be adjusted, but the rest not, because the field width is reset to zero after each insertion.

I think that both operations should use sentries, for sake of consistency with the other inserters and extractors in the library. Regarding the issue of padding in the inserter, I don't know what the intent was.