To be quite honest, these approaches smell really bad to me, because they are basically threatening to put the stability of the interpreter environment at jeopardy by obliging you, in classic “C” style, to have to constantly muck-around with memory issues ... to “have to do things in exactly the right way, throughout your program, ‘or else.’ ”

To put it another way, you are obliging the Perl programming to know and to correctly account-for the present [memory ...] state of the API library, instead of being able to rely upon Perl-managed, garbage-collected objects as you are ordinarily able to do.   I would therefore design the API wrapper in a way that ruggedly eliminates this hazard.   In other words, don’t pass-around “pointers to” anything.   Have Perl allocate an ordinary string-type or hash-type variable and pour the values you need into it.   (Or, the reverse.)

If the Perl-side code needs to make persistent references to some C-library object, let your wrapper code maintain its own list of those objects and to assign a short random-but-unique “moniker” string to each.   These monikers are meaningless, are known only to the wrapper and to the Perl application, and are kept in a list maintained by the wrapper.   The wrapper provides the means by which C-library objects can be created and destroyed, and, through the mechanism of monikers, to make specific references to them, but the wrapper never exposes their addresses to anyone.   (If the Perl program fails to supply a valid moniker, say a nice Perl-world exception will be thrown by the wrapper.)   When a memory-address actually gets passed to the C-library, though, the wrapper is confident that this address, which is known only to itself, is “good,” because the wrapper does know the present memory-state of the API library.   The wrapper now has the ability to clean-up any lingering library-objects reliably when the Perl environment ends, because it has a complete list of them in its monikers-table.

In short, instead of very-dangerously exposing the C-library environment to the Perl environment, use the wrapper as a diplomat:   even though the C-world and the Perl-world do not natively speak with one another, the diplomat undertakes to provide a rugged environment that both of them can understand and which protects them from one another.   The diplomat is also the one that tries to wear the “acid-proof underwear,” absorbing any runtime exceptions that may be thrown and translating those exceptions, if they occur, into appropriate Perl-environment terms.