NVgf is part of Perl, not ANSI C or POSIX. It is a preprocessor macro that, from context, must expand to a string constant that completes a printf conversion sequence. What does sv_setpvf(keysv, "NVgf: \"%s\"", NVgf) produce? (That might produce an error; I am guessing that sv_setpvf behaves like C sprintf but puts the result into a Perl SV.) From context, that must be a printf conversion character; what do ANSI C and POSIX say that character is supposed to do?

I think we can forget all about "NVgf". It has nothing to do with the problem.
Below is a shorter, clearer demonstration of the issue - one that makes no mention of "NVgf".

It's really only of interest when run on a perl whose perl -V:nvsize is 8.
If anyone can get this script to pass its test on such a perl on Ubuntu, then I'd love to see the perl -V output and also the Ubuntu version number.

use strict;
use warnings;
use Test::More tests => 1;

use Inline C => Config =>
 BUILD_NOISY => 1,
;

use Inline C => <<'EOC';

SV * foo(SV * arg, int if_branch) {
  SV * keysv;
  char buff[32];

  keysv = NEWSV(0, 32);

  /* Make sure arg is an NV */
  if(!SvNOK(arg)) croak("Not a valid arg for this demo");

  if(if_branch) {
    sv_setpvf(keysv, "%.19g", SvNV(arg));
  }

  else {
    sprintf(buff, "%.19g", SvNV(arg));
    sv_setpvf(keysv, "%s", buff);
  }

  return keysv;
}

EOC

my $d = 2 ** 63;

my $if   = foo($d, 1); # uses if branch
my $else = foo($d, 0); # uses else branch

is($if, $else, 'they are the same');
[download]

I can see only 2 possible explanations for the test failing:
1) it's a bug in the way that sv_setpvf assigns the string to the SV;
2) it's something that I haven't yet thought of

I've gone cold on the notion that there's something invalid about using sprintf in the XS environment.
It's the one that's delivering the sane result, agreeing both with what happens in the C environment and with what I expect.

I'll ultimately post that demo script in a bug report to RT (and provide a link to it here) unless someone can convince me that there's no perl bug.

I am guessing that sv_setpvf behaves like C sprintf but puts the result into a Perl SV

Yes, that's right - sprintf writes to a string buffer, sv_setpvf writes directly to the SV's PV slot.
The perlclib documentation specifically recommends using sv_setpvf instead of sprintf, which would not be very good advice if sv_setpvf is buggy.

Cheers,
Rob