It's not necessarily the file descriptor number that matters, but rather the OS-internal info (data structure) it refers to. If you dup(2), (">&" in Perl), you get another file descriptor (new number) holding the same info.

Consider the following simple sample CGI, which hangs (for essentially the same reason that you've described):

#!/usr/bin/perl

if (my $pid = fork) {
    print "Content-Type: text/plain\n\n";  

    print `lsof -p $$ -a -d 0-20`;     # for parent

    print `lsof -p $pid -a -d 0-20`;   # for child

    
} elsif (defined $pid) {

    # this creates a dup of file descriptor 2, as descriptor 3
    open STDERR2, ">&STDERR" or die "Can't dup STDERR: $!";

    close STDOUT;
    close STDERR;

    # this makes the parent process hang for 5 sec, because
    # Apache waits for the pipes associated with stdout/stderr
    # to be closed CGI-side
    sleep 5;
    
    exit;
    
} else {
    die "Couldn't fork: $!";
}
[download]

The output you get is something like

COMMAND   PID   USER   FD   TYPE DEVICE SIZE      NODE NAME
hang.pl 25839 apache    0r  FIFO    0,6      429306451 pipe
hang.pl 25839 apache    1w  FIFO    0,6      429306452 pipe
hang.pl 25839 apache    2w  FIFO    0,6      429306453 pipe
hang.pl 25839 apache    3r  FIFO    0,6      429306456 pipe
hang.pl 25839 apache    9w  FIFO    0,6      428685687 pipe
COMMAND   PID   USER   FD   TYPE DEVICE SIZE      NODE NAME
hang.pl 25840 apache    0r  FIFO    0,6      429306451 pipe
hang.pl 25840 apache    3w  FIFO    0,6      429306453 pipe
hang.pl 25840 apache    9w  FIFO    0,6      428685687 pipe
[download]

As you can see in the NODE column, the unclosed (dup'ed) FD 3 in the child (the second lsof output) is the same node (i.e. 429306453) as FD 2 (stderr) in the parent. This is why Apache is still waiting, despite FD 1/2 already having been closed.