...but just to file descriptor 2.

Still, it's a little weird that it only prints to file descriptor 2 (hard-wired), if STDERR is closed. I.e., if you reopen STDERR after fd 2 has been taken by something else, so STDERR is then associated with fd 3 for example, the warning is nicely printed to fd 3, not fd 2...

In other words, it seems this behaviour is explicitly coded somewhere as a fallback for when STDERR is closed.

Still, it's a little weird that it only prints to file descriptor 2 (hard-wired), if STDERR is closed.

Uhm, the kernel itself doesn't know anything about stderr. It's a convention used by utilities. And the convention is, "file descriptor 2 is stderr". (Just as file descriptor 1 is stdout, and file descriptor 0 is stdin).

Making the file descriptor variable would break many things, not in the least the expectation of users.

Uhm, the kernel itself doesn't know anything about stderr.

With "it" I was referring to Perl, not the kernel...

What I find weird is that while Perl normally is printing warnings to whatever file descriptor is associated with the Perl file handle STDERR (typically 2, but not necessarily), it no longer seems to go via STDERR when it's closed (which would mean to just not print), but simply prints to fd 2 anyway — that's what I meant with "hard-wired".

Making the file descriptor variable would break many things, not in the least the expectation of users.

The file descriptor (associated with STDERR) is variable — as long as STDERR isn't closed:

#!/usr/bin/perl

close STDERR;
open AA,     ">/tmp/myfd2" or die $!;   # gets fd 2
open STDERR, ">/tmp/myfd3" or die $!;   # gets fd 3
warn "Hello";
[download]

$ strace -eopen,write ./849816.pl
...
open("/tmp/myfd2", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 2
open("/tmp/myfd3", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
write(3, "Hello at ./849816.pl line 6.\n", 29) = 29
      ^
[download]