I can not reproduce this with the latest stable
snapshot:

# php -n -r 'require("test.php");'
begin
/home/jani/test.php(3) : Fatal error - Call to undefined function:  f()

Try this. ('-n' is for not using any php.ini)

I have tried your suggestion same test file and with:
php4-STABLE-200303210630 (March 21)
I get the same results:
[greg@p3 junk]$ php -n -r 'require("junk.php");'
begin
[greg@p3 junk]$ php -r 'require("junk.php");'
begin
[greg@p3 junk]$ php junk.php                 
begin

Fatal error: Call to undefined function:  f() in /usr/local/apache/htdocs/common/test/junk/junk.php on line 3
[greg@p3 junk]$ 

Perhaps the difference is in our configure options.
Mine are:
./configure --with-dom --with-zlib-dir=/usr/include --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --with-xml --enable-track-vars

Please let me know if we need to split this but into two:
have you tested the issue of error messages not going to /dev/stderr or only the -r issue?

Try this with latest stable snapshot:

# rm config.cache 
# ./configure --disable-all --disable-cgi && make clean && make
# sapi/cli/php -n -r "require('test.php');"

I think you're just doing something wrong / have something
setup very differently in your server..

I built it again, per your instructions and get the same result:
[root@p3 php4-STABLE-200303210630]# sapi/cli/php -n -r "require('/htdocs/common/test/junk/junk.php');"
begin
[root@p3 php4-STABLE-200303210630]# 

Do I need a more recent snapshot than that?
I'm using the same test file: 
/htdocs/common/test/junk/junk.php:
<?php 
echo "begin\n";
f(); // undefined function; fatal error
echo "end\n";
?>

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I absolutely cannot replicate the problem you've described using the latest sources.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


..and can not reproduce..

I had the same problem for a very-very long time while I managed to find out what the problem was. Maybe the reporter of this bug made the same mistake what I did. 

Shortly: the error_reporting configuration was wrong in my php.ini. 

this was bad:
error_reporting  =  E_ALL ^ E_NOTICE

this became good:
error_reporting  =  E_ALL & ~E_NOTICE

The reason was that from the manual of the error_reporting() function I just cpoied the "E_ALL ^ E_NOTICE" expression into the php.ini thinking it will be evaluated in this form. No, it will be not! Instead of the exclusive OR operator there is only AND NOT. 

Maybe this will help someone else too. :) 

Regards,

Csongor