You are mistaken in blaming v. This is actually a bug in unpack that was fixed in 5.10.0.

for (
    [ 127, v4.127 ],
    [ 128, v4.128 ],
    [ 160, v4.160 ],
    [ 194, v4.194 ],
) {
    my ($x, $vstr) = @$_;

    # Workaround
    utf8::downgrade(my $vstr_dn = $vstr);

    printf(
        "got: %04X   " .
        "workaround: %04X   " .
        "expecting: 04%3\$02X or %3\$02X04\n",

        unpack('S', $vstr),
        unpack('S', $vstr_dn),
        $x,
    );
}
[download]

< 5.10.0:

got: 7F04   workaround: 7F04   expecting: 047F or 7F04
got: C204   workaround: 8004   expecting: 0480 or 8004
got: C204   workaround: A004   expecting: 04A0 or A004
got: C304   workaround: C204   expecting: 04C2 or C204
[download]

≥ 5.10.0:

got: 7F04   workaround: 7F04   expecting: 047F or 7F04
got: 8004   workaround: 8004   expecting: 0480 or 8004
got: A004   workaround: A004   expecting: 04A0 or A004
got: C204   workaround: C204   expecting: 04C2 or C204
[download]

Before 5.10.0, unpack used the internal buffer of its inputs with no regards to how the string was encoded within that buffer.