then all I'd like to see is the description of situations where the kernel would close your file descriptor

The mistake you keep making is assuming that it must be the (a) OS kernel that is doing this.

Perl is perhaps a more likely target for responsibility. For example:

{ 
    my $sock = new IO::Socket::INET( 'localhost:12345' );
}
## Here the handle is closed.
[download]

And:

for( 1 .. 2 ){ 
    my $sock = new IO::Socket::INET( 'localhost:12345' );
}    
## The first handle was implicitly closed during the second iteration.
[download]

These examples probably won't convince you, because the scoping is too obvious. But scoping isn't always so obvious, especially when programming in the "global state and gotos" style often required by event-driven architectures.

Similarly, this is normally perfectly fine:

...
    my $client = $svr->accept;
    async {
        ## do things with $client
    }->detach;
[download]

But, this usually not:

...
    my $client = $svr->accept;
    async {
        sleep 10;
        ## attempts to use $client fail
    }->detach;
[download]

The reason is that before the thread gets around to using its copy of the client handle, the parent thread has accepted another client. Now imagine the sleep isn't a programmed delay, but rather one caused by system loading (cpu; memory; IO) preventing the new thread getting up and running in a timely manner, so that the parent thread implicitly overwrite (and therefore closes) $client before the child thread gets to the point where it increments the reference count.

But you'll dismiss that as a "threads-issue".

I can't offer you an explanation of the linux example I cited -- I don't know the guy, nor do I do Linux -- but if the p5p guys took his perlbug seriously enough to patch perl; that's good enough for me to believe that it was a real issue.

I can also find other references to linux sockets mysteriously going awol, even outside of Perl. What I cannot do is pass judgement on the validity of the claims.

But even if every single occasion when an attempt is made to remove a closed file handle from an IO::Select object is down to programmer error; silently doing nothing and thus screwing the entire select loop is ... is ... shall we stick with: not very friendly.