Confirmed in 5.4.5.  In the process of verifying the change(s) that introduced 
this issue:

--------------------------------------------------------------------------------
object(A)#2 (1) {
  ["@attributes"]=>
  array(1) {
    ["attr"]=>
    string(9) "Some Attr"
  }
}
--------------------------------------------------------------------------------
object(A)#3 (2) {
  ["@attributes"]=>
  array(1) {
    ["attr"]=>
    string(9) "Some Attr"
  }
  [0]=>
  string(10) "Some Value"
}
--------------------------------------------------------------------------------

Andrew -

Would you mind taking a look at this? I reverted 
1e3b32c777829f61fa9a18278e0647e9112d96ea locally, and array typecasting works 
fine without the patch.  Also, this patch causes the last child in an element to 
be skipped in the case pointed out in this 
report.  I wanted to get your input before I move forward with any changes.

After reverting locally do all the unit test cases for SimpleXML still pass? This was not the case prior to the patch (one test was failing).

I'll work on reverting the change locally on my end tonight and see if I can reproduce the bug and fix.

I can confirm that reverting that patch does fix the bug; however, it causes the original test to fail again:

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
SimpleXML: cast to array [ext/simplexml/tests/034.phpt]
Bug #51615 (PHP crash with wrong HTML in SimpleXML) [ext/simplexml/tests/bug51615.phpt]
=====================================================================

See: ext/simplexml/tests/034.phpt for more information.

Ignore bug51615.phpt for now. That is just a side effect of test 34.

I would actually prefer if I could take the first stab at this bug myself since it was clearly introduced in my code. I'd be hesitate to just revert the changes since that would break test 34.

I think that would make more sense.  Thanks, Andrew.

I think we should revert the previous fix at now, since this new bug is more 
critical than the previous one.

and I think the key problem there is that we can not tell iterating from 
convert_to_array in the sxe_get_prop_hash

without that, I don't think we can get a good fix for the 034.phpt

It causes not only wrong var_dump and print_r, but also wrong boolean cast.

Test script:
------------
$xml = <<<XML
<?xml version="1.0"?>
<a>
    <b>Some String</b>
</a>
XML;

$b = simplexml_load_string($xml)->xpath('/a/b');
var_dump((string)$b[0]);
var_dump((bool)$b[0]);

Expected result:
----------------
string(11) "Some String"
bool(true)

Actual result:
--------------
string(11) "Some String"
bool(false)

The following workaround seems to fix both dumping and type casting:

<?php

class SimpleXMLElement_CloneFix extends SimpleXMLElement
{
    public function xpath($path)
    {
        $result = parent::xpath($path) ?: array();
        foreach ($result as $node) {
            $this->_fixNode($node);
        }
        return $result;
    }

    protected function _fixNode(SimpleXMLElement $node)
    {
        if (!$node && (string)$node) {
            $dom = dom_import_simplexml($node);
            $dom->parentNode->replaceChild(clone $dom, $dom);
        }
    }
}

Unfortunately, the same approach does not work for children() method, because of mysterious nature of its returned value.
Despite returned object manifests itself as an instance of SimpleXMLElement, it does not behave as such.
For instance, it is incompatible with dom_import_simplexml().
So, what kind of SimpleXMLElement is that?

Is there something happening with this issue? It is now in stable debian and others :/

???

Why you develop new features, when the old ones are unusable?

So any update? this issue is hanging here for almost two years ? Will you fix it ?

Thanks for your replies.

PHP - the reliable language of the future.

Will this ever be fixed?

This bug still exists in any PHP versions higher than PHP 5.4.0. Tried 5.6.3, 5.4.35 and 5.5.19 and all return the same wrong result.

Confirmed: <http://3v4l.org/t2RHn>.

This issue seems to be related to bug #67116, bug #67572, bug #68946, bug #69169 and bug #69491.

After further investigation it turned out that this is a duplicate
of bug #66084.