I'm on the phone so I can't verify, but I don't think this has anything to do with DOMAttr but rather just the fact that var_dump doesn't escape its output and thus the browser converts it.

Edit: Also note that PHP 7.4 is unsupported.

No. I'm testing it on CLI.

# php -r '$node = new DOMAttr("foo","bar"); $node->nodeValue = "xx1yy"; var_dump($node->nodeValue);'
string(5) "xx1yy"

Bug confirmed https://3v4l.org/Xf27Y , given that Attrs in a browser don't work the same way and that I can't see either the HTML 4 or Living Standard specifying any transformations should happen, but this is likely an issue with libxml and not PHP.

Writing the nodeValue is implemented by calling xmlNodeSetContentLen(), and its documentation states:

Replace the content of a node. NOTE: @content is supposed to be a piece of XML CDATA, so it allows entity references, but XML special chars need to be escaped first by using xmlEncodeEntitiesReentrant() resp. xmlEncodeSpecialChars().

Our implementation does not escape, though.

Reading the nodeValue is implemented by calling xmlNodeGetContent(), and its documentation states:

Entity references are substituted.

Changing this would cause a pretty serious BC break.

I think this qualifies as bug, but due to the BC break when we fix it, I'm reluctant to do this.

@beberlei, thoughts?

Fixed via GH-10132.

Do you think it needs a changelog table entry in the manual?

Yes. This should happen for us by the docs maintainers because there's an UPGRADING entry. But I opened PR php/doc-en#2520 already so it will certainly not be forgotten.

Reverted the fix because of quite big BC breaks. See #11469

This is fixed in the new opt-in spec-compliance mode, which was merged in #13031.
For more information about the opt-in mode, please see https://wiki.php.net/rfc/opt_in_dom_spec_compliance.
In short: the behaviour of the old DOM classes are unaffected for backwards-compatibility reasons. There are new DOM classes where your code is correctly handled.