I am not sure what is going on here, but I suspect something around the handling of the default flavor (com.apple.traditional-mac-plain-text) when extended characters such as SNOWMAN are present.
It appears that a workaround is to use a specific encoding, and a flavor that corresponds to that encoding. Something like the following:
#!/usr/bin/env perl
use 5.010;
use charnames qw{ :full };
use Encode;
use Mac::Pasteboard;
binmode STDOUT, ':encoding(UTF-8)';
$pb = Mac::Pasteboard->new();
# First part of gist
say 'First part of gist: pbcopy, then $pb->paste';
system qq{ echo "\N{SNOWMAN}" | pbcopy };
say decode( 'UTF-8', $pb->paste( 'public.utf8-plain-text' ) );
# Second part of gist
say 'Second part of gist: $pb->copy, then pbpaste';
$pb->clear();
$pb->copy( encode( 'UTF-8', "\N{SNOWMAN}" ), 'public.utf8-plain-text' );
system 'pbpaste';
say '';
__END__
At my current level of understanding, I am not sure how to proceed, since what flavors are guaranteed available is unclear to me, and what encodings they correspond to may not be straightforward. As an example of the latter point, public.utf16-plain-text seems to be UTF-16LE (i.e. no BOM) not UTF-16 (i.e. with leading BOM). Hopefully more research will clarify this.
As a possible complication: my testing was done with Mac OS 10.8.3 Mountain Lion, but I believe the interface works back to 10.3 Panther, and I feel the need not to break anything under Panther -- at least not without going through a deprecation cycle.
