Two distinct issues:

a) The problem starts with the fact that >>null<<, in all it's forms, is a magic word with a single unique value. Thus $a[null] is the same variable as $a[Null], but NOT the same as $a["Null"].  The problem is that 

  "  $a[null]  "

is being read as 

  $a["null"]

which is probably the best way to handle this single ambigious case. SOLUTION: don't use NULL as an array index without quoting it.

b) the difference is simply in the way a boolean is printed to the screen. A true is now displayed as '1', a false is now '' (the empty string). I'm not sure why that was changed. SOLUTION: echo ($cond)?1:0;

i must ask, then - why has the bareword `null' suddenly picked up a special meaning to the scripting engine?  this seems like a *bad* design move to me, since it means that this bareword suddenly behaves differently than before.  it's also not consistent - *are* there other barewords that have special meanings in similar contexts?

also, it's not mentioned at http://www.php.net/version4/incompatibilities.php.  this is a little dangerous.

if we maybe introduced a null() *function* i could see it...

moving to doc's problem, since it's clearly not engine bug but doc issue.

It won't work properly with any reserved word, which brings me back to the point : you should always quote constant strings.  The only reason that it works at all is the parser is fixing your mistakes for you.  If you set your

  error_reporting = E_ALL

in your php.ini (and restart php), for the code

  $a[word] = "foo";

you'll see the warning

  Warning: Use of undefined constant word - assumed 'word' in /var/www/html/test2.php on line 3

I'll leave this issue open for someone from the documentation team to catch up with later.

This is neither a bug in PHP, nor a doc bug...I will make
the incompat entry more explicit as soon as I can get to the
CVS, but you can see from the last comment what the problem
is: you are using a predefined constant as a key in an assoc.
array. This would be termed, at best, as "undefined".

Maybe we should look at documenting how the engine corrects bad coding. We often get questions on #php about the engine correcting unquoted string constants and any other behaviour like this. I cant think of any others now but maybe a new chapter on debugging troublesome code or common errors etc is necessary in the manual. This might belong in the FAQ but I think a chapter in the docs wouldnt go amiss. Maybe another thing we should think about doing is including the FAQ in the manual as well as on php.net itself.

James:
  Since you have a better idea of exactly what it is you
want to document, I'm moving this to you. Close it whenever
you think it is sufficently documented.

Any progress on this?

I am currently writing the section 'why is $foo[bar] bad' in the arrays section. It will adress this problem, so that in the future you can say: RTFM

Included big warning in manual about this.

Included big warning in manual about this.