I would go so far as to predict rather-emphatically that it wouldn’t. And, in any case, it would be highly dependent upon (read: “would introduce a whale of a dependency upon ...”) the exact internal implementations of that library. Warning-bells going off all over the place here.

I agree fully. Unless the library provided **deep copy** routines for every relevant struct, this is not going to work.

having been given a live memory-address, how long is that address actually going to be “good?” Your Perl app could now potentially modify (read: “muck around with”) that memory at any future-time.

First: The scenario is that the C library doesn't make any requirements about when the correct free function is called. Only that it should be called. In C that would often (but not always) lead to symmetric allocations/de-allocations to prevent leaks, but there's nothing to say that free_*() can't be called at any time later at the will of a reference count engine.

Secondly: You have alluded to the Perl app "mucking around" earlier. I don't really share that concern. I mean... any Perl module will break spectaculary if the Perl app started trashing its objects. Take the JSON::XS module. What would happen if I did:

my $json = new JSON::XS;
substr($$json,0,1) = 'X';  # the object is a ref to a PV
[download]

I would simply set a byte in the start of *JSON on the C side.

No module needs to protect against a perl app using anything but the defined API on the objects/vars it return.