The second line of this snippet is likely an error. Solution A catches
the error and refuses to compile. The reason is that there is no
specialization of the member template constructor that looks like:

So the expression binds to the unspecialized member template
constructor, and then fails (compile time) because char is not an
InputIterator.

Solution B compiles the above example though. 'a' is casted to an
unsigned integral type and used to size the outer vector. 'b' is
static casted to the inner vector using it's explicit constructor:

explicit vector(size_type n);

and so you end up with a static_cast<size_type>('a') by
static_cast<size_type>('b') matrix.

It is certainly possible that this is what the coder intended. But the
explicit qualifier on the inner vector has been thwarted at any rate.

The standard is not clear whether the expression:

vector<vector<pair<char, char> > > d('a', 'b');

(and similar expressions) are:

undefined behavior.

illegal and must be rejected.

legal and must be accepted.

My preference is listed in the order presented.

There are still other techniques for implementing the requirements of
paragraphs 9-11, namely the "restricted template technique" (e.g.
enable_if). This technique is the most compact and easy way of coding
the requirements, and has the behavior of #2 (rejects the above
expression).

In the previous paragraph the alternative binding will fail if f
is not implicitly convertible to X::size_type or if l is not implicitly
convertible to X::value_type.

The extent to which an implementation determines that a type cannot be
an input iterator is unspecified, except that as a minimum integral
types shall not qualify as input iterators.

[
Kona: agreed that the current standard requires v('a', 'b')
to be accepted, and also agreed that this is surprising behavior. The
LWG considered several options, including something like
implicit_cast, which doesn't appear to be quite what we want. We
considered Howards three options: allow acceptance or rejection,
require rejection as a compile time error, and require acceptance. By
straw poll (1-6-1), we chose to require a compile time error.
Post-Kona: Howard provided wording.
]

[
Sydney: The LWG agreed with this general direction, but there was some
discomfort with the wording in the original proposed resolution.
Howard submitted new wording, and we will review this again in
Redmond.
]

[Redmond: one very small change in wording: the first argument
is cast to size_t. This fixes the problem of something like
vector<vector<int> >(5, 5), where int is not
implicitly convertible to the value type.]

Rationale:

The proposed resolution fixes:

vector<int> v(10, 1);

since as integral types 10 and 1 must be disqualified as input
iterators and therefore the (size,value) constructor is called (as
if).

The proposed resolution breaks:

vector<vector<T> > v(10, 1);

because the integral type 1 is not *implicitly* convertible to
vector<T>. The wording above requires a diagnostic.

The proposed resolution leaves the behavior of the following code
unspecified.

The implementation may or may not detect that A is not an input
iterator and employee the (size,value) constructor. Note though that
in the above example if the B(A) constructor is qualified explicit,
then the implementation must reject the constructor as A is no longer
implicitly convertible to B.