Vertical tabs aren't allowed in XML 1.0 and need to thus be escaped as  or . They are allowed in XML 1.1 but are discouraged as one of the "compatibility characters". Now I'm not sure exactly which rules libxml follows, but at least in this aspect it seems to follow 1.0 when reading. And unfortunately libxml won't automatically escape them when writing.

PHP could, but the question is whether it should. At least whether it should *now*. On one hand, this changes the behavior of code people have been relying on for years, but on the other hand (a) the generated XML may not have been valid to begin with and (b) any parser that accepts invalid unescaped characters should accept the escaped versions transparently - even if humans don't realize they're the same.

The normal answer to this problem is "you have to escape it yourself" (especially when it comes to the addChild/createTextNode problem) but if there's an opportunity to reduce the number of times that's necessary then I'd like to see if we can.

I'm only moving this to Analyzed so someone more familiar with the XML side of PHP can decide what to do.
a) Not a bug, libxml follows XML 1.0 and you have to escape it yourself
b) Not a bug, libxml follows XML 1.1 and it is the one that can't handle \v not PHP
c) Is a bug, PHP should take some measures to escape strings automatically

In my opinion, it is a bug in libxml.
The characters \t \n \r are automatically converted in the method DOMElement::setAttribute correctly to 	 
 
 
but not \v

That's necessary because a raw \nrt in an attribute gets normalized to a space. To keep the character when reading it must have been escaped when writing.
http://www.w3.org/TR/2006/REC-xml11-20060816#AVNormalize 3.3.3 Attribute-Value Normalization
They didn't include \v in there.

In this case I would expect the method to throws an exception if the input is invalid. But not that an invalid XML is created.

I agree, it should never produce invalid XML. Perhaps unexpected markup sometimes (try putting "-->" into a comment) but at least it's valid.

After experimenting more with what libxml encodes and when, I'm satisfied that it's generally consistent: < > & are encoded as needed and normal characters are turned into entities when the document charset doesn't support them.

Control characters besides \nrt are the problem. They should be converted into entities as happens with any other unsupported character. And that's a libxml problem.

Interesting you should mention that about "-->", because that leads to another libxml bug (if they consider it a bug):

<?php
$doc = new DOMDocument();
$node = $doc->appendChild(new DOMElement('my-test'));
$comment = $node->appendChild(new DOMComment("This comment has a double hyphen -- something that isn't allowed in XML."));

echo $doc->saveXML();
$doc->save('c:/tmp/test.xml');

?>
Produces invalid output.