There's a trivial error in the expected result text: the string length produced by var_dump() should be 65, not 59.

It was  decided to leave it as it is (for backwards 
compatibility reasons)

use $dom->createTextNode() for the behaviour you want.

I'm aware of the differences in escaping between createElement() and createTextNode() and neither one does what I describe.  createElement() unescapes NCRs (as I described in the original description) while createTextNode() escapes values.

In a nutshell, using createElement() I end up with "<root> </root>", and using createTextNode() I end up with "<root>&amp;#0160;</root>".

There is no way to generate the literal XML "<root>&#0160;</root>" using either createElement() OR createTextNode()

<root>&#0160;</root> and <root> </root> (the space here being 
a non breakable space) is the same in the XML context... It 
doesn't matter, if your write a character as numerical entity 
or with the actual char. It's the same. You have to live with 
that.

And please don't just assign bugs...

Thanks for the quick response.  I did change the bug status back to "open" but I didn't assign it, tony2001@php.net did.

I believe you're right that this particular example both XML strings are the same, but only because the NCR I used represents a printable character.  A non-printable character must be represented as its NCR.  There's no way to craft a node whose value contains an NCR, and as such, no way to create an element whose value contains non-printable characters.

$dom = new DOMDocument( "1.0", 'UTF-8' );
$dom->appendChild( $dom->createElement( 'root','
' ));
var_dump( trim( $dom->saveXML() ) );

prints out

string(57) "<?xml version="1.0" encoding="UTF-8"?>
<root>&#13;</root>"


Anyway, this is really not a PHP issue (if it is one at 
all), but a libxml2 issue. If you still think this is a bug, 
report it there