Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The class information is needed, see for example

class A {
  private $p;
}
class B extends A {
  private $p;
}

var_dump((array)new B());

I'm sorry but that's a bogus explanation. "Please double-
check the documentation"? What you describe is contrary to 
the documentation.
The reasoning you express also fails completely on my point 
about there being no separator between class name and 
property name. How can you consider this to be reasonable 
behaviour?:

class A {
  private $A;
}
class B extends A {
  private $A;
  public $AA;
}

var_dump((array)new B());

array(3) {
  ["BA"]=>
  NULL
  ["AA"]=>
  NULL
  ["AA"]=>
  NULL
}

Given that this undocumented behaviour is thus proven 
ambiguous, unreliable and contrary to existing docs, how can 
you say that it's 'needed'? Are you saying that there's 
widespread code that depends on this weirdness, when 99% of 
use cases will not expect it?

At the very least this is a valid documentation bug.

There are separators, null bytes.

Well, that's good to know, but it does mean that you're 
justifying undocumented behaviour with yet more undocumented 
behaviour.

I see that these null bytes are there, but they're not 
separators; they're prefixes to both class and property 
name, that is, the resulting array keys are of the form:
NULL<classname>NULL<propertyname>

I still fail to see how this is bogus when it's so wildly 
different to what's documented, and is implemented in such a 
way as to be useful in only the most obtuse of situations, 
to the detriment of all other occasions. One change that 
would make all this much more palatable while preserving the 
additional information AND conforming closer to the docs: 
only provide extended class information for properties that 
are NOT in the current class. For example:

<?php
class A {
private $A;
}
class B extends A {
private $A;
public $B;
}
$a = (array)new B;
foreach($a as $k => $v) {
echo bin2hex($k)."\n";
}
?>

At present this produces:
00420041
00410041

My suggestion is to change that to:

00420041
41

That way we will be in the situation that all unambiguous 
properties in the current class are available using their 
unmodified names, just like the docs say. The only remaining 
issue is with protected values - I don't know that 
preserving that status is of much value anyway - it's not as 
if you can cast back from an array to an object anyway.

It turns out that this was actually a documentation problem, 
and apparently a fix has been posted in docs. So, the 
'strange' entries are intentional, and the new docs will 
explain them.

We won't mark as closed until the doc patch has actually
been submitted (currently in review).

OK, Thanks for dealing with it.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

The change should appear on the documentation next time it's
built.