After digging a bit into standards, I found following :
Here, I am trying to initialize vector<char>  using two string literals, not two chars.
using vector(initializer_list<T>). In this case, vector(initializer_list<char>).
But the type of a string literal is "array of n const char", so the initializer-list constructor is not a match.
This doesn't result in compiler error, since the compiler is able to find another constructor that matches
§13.3.1.7¶1 explains the rules :
"When objects of
  non-aggregate class type T are list-initialized, overload resolution
  selects the constructor in two phases: 
— Initially, the candidate
  functions are the initializer-list constructors of the class T and the
  argument list consists of the initializer list as a single argument
  [which we have seen didn't match]. 
— If no viable initializer-list
  constructor is found, overload resolution is performed again, where
  the candidate functions are all the constructors of the class T and
  the argument list consists of the elements of the initializer list."
And the match in this case is :
template <class InputIterator> vector(InputIterator first, InputIterator last)
The type of InputIterator has no info of T in the vector<T>. 
So even if I'm initializing a vector<char>, the two arguments can be of arbitrary type. 
The only requirement is that they stick to InputIterator property, which const char[] happens to do.
The constructor believes it has been passed two iterators to the same sequence, 
but it has actually been passed iterators to two completely different sequences, "y" and "z".
So the result of this program is undefined .
Thanks to chris's comment 
This is post is exactly same as he mentioned over there. See this