That does explain it. I was still leery of what goings on inside the SvIOK/SvUOK macros might be influencing it, so I substituted a volatile variable as the conditional:

volatile int n;

void test2 ( SV *sv ) {
    double d1 = n ? SvNV( sv ) : SvIV( sv );
    double d2 = n ? SvNV( sv ) : SvUV( sv );
    return;
}
[download]

And sure enough that silenced the warnings.

Whilst that definitively takes XS off the hook, moving it to either the C/C++ standard or the compiler, it still leaves a bad taste in the mouth. Given this is a warning rather than an error; and that even the wording "possible loss of data" hedges its bets; I'd personally prefer the warning to be issued if there is the 'possibility of data loss', rather than not issued if there is the 'possibility that no data will be lost'.

That said, given my enmity for things like const correctness and PerlCritic, I wonder if I'm in danger of asking for a similar level of cry-wolfism?