Can you show an example where this could somehow be useful?
(you can always use __FILE__ and __LINE__ :)

Yes, below is an example of how I'm using it. 
The purpose is to work around the limited arguments passed to custom error handlers, installed with set_error_handler(), which do not receive class and function information. 

The following function replaces trigger_error() by talking directly to my custom error handler ('phpc_error_handler', omitted for brevity below), using debug_backtrace() to pass class and function info for prepending to error messages.

<?php
///////////////////////////////////////////////////////
/*
  phpc_trigger_error( $errorMessage,$errorCode,$debugBacktrace=NULL )
    same as PHP built-in trigger_error, with optional parameter
    generate error message including debugging information
    
  USAGE:
  phpc_trigger_error( $errorMessage,$errorCode,debug_backtrace() );
*/
/////////////////////////////////////////////////////////
function phpc_trigger_error( $errorMessage,$errorCode,$debug_backtrace=NULL ){ 

	$errfile=__FILE__;
	$errline=__LINE__;
	$errclass="";
	$errfunction="";
	if (isset($debug_backtrace[0])){
		$errfile=$debug_backtrace[0]['file'];
		$errline=$debug_backtrace[0]['line'];
		$errclass=$debug_backtrace[0]['class'];
		$errfunction=$debug_backtrace[0]['function'];
	}
	if (!empty($errclass)) $errclass.='::';
	if (!empty($errfunction)) $errfunction.='(): ';
    $errorMessage=$errclass.$errfunction.$errorMessage.' ';
    phpc_error_handler ($errorCode,$errorMessage,$errfile,$errline);
} // phpc_trigger_error()
?>

I forgot to point out why the phpc_trigger_error() example is not an adequate workaround for the lack of consistency in debug_backtrace().

Although I use __LINE__ and __FILE__ when $debug_backtrace[0] is not set, these values are pretty useless since they are set from the context of the phpc_trigger_error function, NOT from the place where it was called from; where the error occured. If debug_backtrace() always returned __LINE__ and __FILE__ we would have everything we need.

Just pass the __FILE__ and __LINE__ to your phpc_trigger_error() function, problem solved.

e.g.

phpc_trigger_error( $errorMessage,$errorCode,__FILE__, __LINE__, debug_backtrace() );

Your solution is not elegant: adding extra parameters when debug_backtrace() would be enough if it behaved consistently in all cases.

This is also a documentation bug. Please do not set to 'bogus'. How can a feature request be 'bogus'?

fwiw, I also feel this is a valid (and worthy) feature request and assumed debug_backtrace() behaved as such.

I just realized that the expected result I entered is not consistent with how debug_backtrace() works: function debug_backtrace must also be listed. Here's a revision.

Expected result:
----------------
[greg@p3 xobj]$ php /tmp/a.php
Array(
    [0] => Array
        (
            [file] => /tmp/a.php
            [line] => 1
            [function] => debug_backtrace
            [args] => Array
                (
                 )
        )
)

Here's quickie patchie which doesn't drop the debug_backtrace() call itself out of the result array.

We could add an optional parameter to debug_backtrace()
which makes it include itself in the result too. Leaving 
open for discussion, I don't need this myself, but if 
enough people think it's useful.... :)

Hint: 
https://www.paypal.com/xclick/business=sniper@php.net&no_note=1&tax=0&currency_code=EUR


diff -u -r1.124.2.9 zend_builtin_functions.c
--- Zend/zend_builtin_functions.c       16 Jun 2003 15:55:07 -0000      1.124.2.9
+++ Zend/zend_builtin_functions.c       23 Jun 2003 22:32:13 -0000
@@ -1210,11 +1210,6 @@
 
        ptr = EG(current_execute_data);
 
-       /* skip debug_backtrace() */
-       ptr = ptr->prev_execute_data;
-       cur_arg_pos -= 2;
-       frames_on_stack--;
-
        array_init(return_value);
 
        while (ptr) {

This is still present in 5.5 and in the 5.6 betas.