Here's a patch for this issue:

--- php-5.2.4-vanilla/main/main.c       2007-11-01 15:20:37.000000000 +0200
+++ php-5.2.4/main/main.c       2007-11-01 17:26:45.000000000 +0200
@@ -957,11 +957,15 @@
                                if (!SG(headers_sent) &&
                                        SG(sapi_headers).http_response_code == 200
                                ) {
-                                       sapi_header_line ctr = {0};
-
-                                       ctr.line = "HTTP/1.0 500 Internal Server Error";
-                                       ctr.line_len = strlen(ctr.line);
-                                       sapi_header_op(SAPI_HEADER_REPLACE, &ctr TSRMLS_CC);
+                                       if (!EG(current_execute_data) ||
+                                               !EG(current_execute_data)->opline ||
+                                               EG(current_execute_data)->opline->opcode != ZEND_INCLUDE_OR_EVAL) {
+                                               sapi_header_line ctr = {0};
+
+                                               ctr.line = "HTTP/1.0 500 Internal Server Error";
+                                               ctr.line_len = strlen(ctr.line);
+                                               sapi_header_op(SAPI_HEADER_REPLACE, &ctr TSRMLS_CC);
+                                       }
                                }
                                /* the parser would return 1 (failure), we can bail out nicely */
                                if (type != E_PARSE) {

A vote from me. Parse error in eval'ed code should not alter HTTP status 
(well, as long as one is not able to catch it).

It's been over 4 years and the fix is known!  I can't believe I spent all day yesterday debugging this.  I was filing a bug report and the system found this match.  I'm using php 5.4.3.  I'll paste the rest of my notes into this comment because they include references to the documentation, updated line numbers, and other details not present in the original report.  Please commit a fix!  More and more people will hit this as more and more people use AJAX.
--- Description: ---
http://us2.php.net/manual/en/function.eval.php states:
If there is a parse error in the evaluated code, eval() returns FALSE and execution of the following code continues normally.

In reality, eval() can have the side effect of setting the response code to 500 and leaving it at 500.  My guess is that this has gone unnoticed because everything else proceeds normally enough to produce an otherwise normal page and browsers are willing to display such pages even though the response code is 500.  However, wget complains about the 500 and an AJAX framework that checks response codes may refuse to display the page.  I believe the point of continuing normally is that eval() should not ruin the current page.

I think the fix is to put
"&& EG(current_execute_data)->opline->extended_value != ZEND_EVAL"
into the "if" block at line 1132 of main.c.  The "if" decides whether to set the response code to 500 in the case of a parse error.

I just noticed the exit status is also modified by eval() a few lines earlier.  Given the function description, it doesn't seem correct to force the exit status to 255.  I guess the same "if" applies.

I'm guessing it is redundant to make sure the type is E_PARSE in the the case of ZEND_EVAL, but someone how knows more about internals should probably confirm that.
--- Test script: ---
<?php
eval('0+');
print "hello world\n";
?>
--- Expected result: ---
hello world

with exit code 0
--- Actual result ---
That looks good in a browser, but fails with wget (and my AJAX framework and anything else that relies on the response code).  On the command line, the exit code is 255.

A fix is available in
https://github.com/jabouillei/php-src/tree/issue-43177

The changes are in main.c and zend.c.  github shows other files as being modified also, but that's probably from me not understanding part of the merge process.  My changes are in commit a65037ef46.