And now to your belated and unannounced update.

you haven't ruled out doing something like $pascal_bytes = chr(length($bytes)) . $bytes;. For long enough strings, it upgrades without calling upgrade and without Perl assigning any meaning to the string.

That is wrong in so many ways.

First, I conclude that you are referring to this:

C:\test>p1
use Devel::Peek;;

sub toPascal{ return chr( length $_[0] ) . $_[0] };;

Dump toPascal( 'x' x $_ ) for 255, 256;;
SV = PV(0x28d280) at 0x3c599e0
  REFCNT = 1
  FLAGS = (TEMP,POK,pPOK)
  PV = 0x3cb28f8 "\377xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxx
  CUR = 256
  LEN = 264

SV = PV(0x3c3aa30) at 0x3c599c8
  REFCNT = 1
  FLAGS = (TEMP,POK,pPOK,UTF8)
  PV = 0x3cb2a28 "\304\200xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]
  CUR = 258
  LEN = 264
[download]

Meaning has been assigned. Note the UTF8 flag is set in the second example.

But then, it makes no sense to try and create Pascal strings longer than 255 bytes, because P-strings are defined as being prefixed with a length byte.

But even if that where not the case--if length could be of any size--using SvPVbytes() wouldn't help any. Because unless the XS routine was specifically designed to work with this non-native encoding, its never going to do the right thing:

SV *func( SV *first, SV *second ) {

    return sv_catsv( first, second );
}
[download]

Just another red-herring.