I'm afraid that is caused just by the line
    $a = "foo";
which re-sets the $a variable to string, so it is no longer an array and can't be enumerated by next loop...

Please read properly before posting. And also read 
http://www.php.net/foreach , especially the part with "Note:  Also note that foreach operates on a copy of the specified array and not the array itself."

And as was said, it only happens if you do $a =& $a; before the foreach clause. If you don't do it, you get the expected result.

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

.

Care to explain why doing $a =& $a; before the loop should affect the behaviour? In my (and some others whom i talked to) opinion that behaviour is bogus. And if it does make sense, it should be reflected in the documentation (where it isn't), because this caused someone an error with a high WTF factor in an application.
Example:
foreach ($_SESSION['something'] as $foo) {
    do_something;
    $something = "foo";
    do_something_else;
}
Breaks on a server with register_globals on.
    

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

Don't use register globals. And don't use it for example because of this problem.

Second, a reference variable and a normal variable do NOT result in foreach copying the whole array. Instaed not accessing the data by ref [foreach($ar as &$data)] only results in copying the data. Therefor the array is still ste same and if you change the array in the loop then obviously you affect the loop.

To et@php.net:

> especially the part with "Note:  Also note
> that foreach operates on a copy of the specified
> array and not the array itself."

Sorry, but that especially this paragraph is very obscure, because a subsequent sentence states "However, the internal pointer of the original array is advanced with the processing of the array."

Furthermore, this is partially subject of recently opened bug #28939 or #28939.

But there I really don't see any problem. Coincidental overwriting of registered global is IMO really not bug but stupidity of the author :-)

Sorry for mistyping the bug numbers: bug #28939 and bug #29687

I don't use register globals. But there are lots of servers which do.
1st, you're contradicting the Documentation, which clearly states that the array should be copied: "Note:  Also note that foreach operates on a copy of the specified array and not the array itself."
2nd, you didn't specify the difference between using a reference variable and a normal variable.
If you do 
foreach($array as $v) {
   array_push($array, 0);
}
modifying the array, it doesn't affect the loop. By your reasoning, it should?

Please don't bogus it again, because it is either a problem with the documentation or with the implementation.

Yes, sorry, now I see you are true. When I tested the example above I didn't try to comment out the line '$b =& $a;' so I thought the array is always using directly from foreach on each loop. So IMHO there is either badly written documentation or bad implementation (which is btw relevant to that two bugs I posted before).

BUG UPDATE: Now I noticed that if you first unset() the $a variable before re-setting it to the string (or anything else), it is working properly.

Stefan, please look into it.
If it works as expected, than it's a docu problem, probably.

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.

"Unless the array is referenced, foreach operates on a copy of the specified array and not the array itself."