That's because $xml->elem2 exists and isn't null. isset works differently.

According to the docs, ?? is the same as isset, just a different syntax. Maybe the documentation should be updated?

> That's because $xml->elem2 exists and isn't null.

If it is set and it is not NULL, shouldn't isset() return TRUE?
The current behavior (<https://3v4l.org/1NYAA>) looks like a bug
to me.

I'm being hypocritical: I've said before that $x ?? $y should be equivalent to isset($x) ? $x : $y, so this really is more of a bug than a request.

As I try to look deeper, this does indeed seem more like a bug - albeit one that may uniquely affect SimpleXMLElement. I could keep going into this but I don't know enough about the engine to tell why the same opcodes don't invoke has_property on SimpleXMLElement but do call __isset on userland classes. I do see that it uses a FETCH_OBJ_IS instead of the ISSET_ISEMPTY_PROP_OBJ jmping logic that isset() does... So does FETCH_OBJ_IS differ for internal and userland code?
https://3v4l.org/DF8AE/vld#output

I'll bump to Verified but I'm not confident enough in my analysis to go to Analyzed.

@cmb: No doubt that's part of the magic. I'd guess that the idea was to allow code like
  foreach ($xml->zero_or_more_elements as $e) {
without having to wrap it all in an isset check. Breaking it would be a BC thing, but I wonder how often that magic is actually relied upon...
The inconsistency is a bit of a bother. Has anyone else ever noticed it? With a quick search I haven't found any bug reports mentioning it. Maybe it's worth breaking?

> So does FETCH_OBJ_IS differ for internal and userland code?

It doesn't appear to be so. Consider <https://3v4l.org/PJGqt>. In
either case (SimpleXMLElement and stClass) ZEND_FETCH_OBJ_IS takes
the same code path, and calls zobj->handlers->read_property()[1].
That works as expected for all userland and most internal objects,
but not for SimpleXMLElements.

So it boils down to SimpleXMLElements allowing to read properties,
which they otherwise claim to not exist. At least that is one
possible interpretation. The other would be that the null coalesce
operator would have to be compiled into the same opcodes as the
repective `isset($x) ? $x : $y`. Still, I'd find the
SimpleXMLElement inconsistency to be confusing, at best. I can't
assess the impact of changing the behavior, though.

[1] <https://github.com/php/php-src/blob/PHP-7.1.0beta3/Zend/zend_vm_def.h#L2066>