It captures STDERR from child processes without any calls to system or backticks or whatever having to be called in a special way.

That's because child processes inherit their stdin/stdout/stderr from their parent processes.

But file handles are OS level entities, not language specific entities. A tied filehandle is a perl-level entity; it cannot be inherited by a C program.

This sounds promising.

Here is a script that saves, redirects, and restores STDOUT and STDERR
+ using various methods:
    #!/usr/bin/perl
    open(my $oldout, ">&STDOUT")     or die "Can't dup STDOUT: $!";
    open(OLDERR,     ">&", \*STDERR) or die "Can't dup STDERR: $!";
    
    open(STDOUT, '>', "foo.out") or die "Can't redirect STDOUT: $!";
    open(STDERR, ">&STDOUT")     or die "Can't dup STDOUT: $!";
    
    select STDERR; $| = 1;  # make unbuffered
    select STDOUT; $| = 1;  # make unbuffered
    
    print STDOUT "stdout 1\n";  # this works for
    print STDERR "stderr 1\n";  # subprocesses too
    
    open(STDOUT, ">&", $oldout) or die "Can't dup \$oldout: $!";
    open(STDERR, ">&OLDERR")    or die "Can't dup OLDERR: $!";
    
    print STDOUT "stdout 2\n";
    print STDERR "stderr 2\n";
[download]

The OP is already doing that, and it won't work for tied handles for the reasons already stated, so it doesn't help the OP.

Isn't there some way to redirect it to a subroutine

The child process cannot access variables or call subroutines in your process. You will need to have the child write to a pipe from which you will read, then you can pass what you read to a subroutine.

or file handle instead?

huh? "Redirecting data sent to a file handle to a file handle" makes no sense.