I agree that data translations will be costly. But nothing stops using raw memory pointers typecasted (i.e. interpreted) to the appropriate data structure. In plain C that would be akeen to typecasting raw memory/void to a struct. In OOP, an SV could be any class implementing the SV interface with, say, slot(name, value). Since all these will be part of the same process, it wont be necessary to use shared memory etc.

It's true that any XS code using SV sv; sv.IV = 42; will break (is this the sort of tricks you mentioned doing?). But, perlguts's doc shows that the proper way is to use sv_setiv(&sv, 42) i.e. a setter macro/function which it is very easy for the suggested intermediate layer to hijack transparently. But perhaps it all leads to re-inventing a virtual machine, which you mentioned.

PS. I respond to this thread, and I am sorry if I waste your time with possible nonsense, as a means of throwing ideas/brain storming. I consider it fundamental that the "modernisation" process starts from the guts. Or equal attention be given to the guts too. And having a data-exchange framework as a when-all-else-fails option for the API when dealing with different Perl versions but also for when accessing external libraries with Platypus and also when accessing external environments (like R) and their native data structures (like R's data.frame) would be great and future-proof and make Perl a true polyglot.

refs: Parrot Overview and SO thread https://stackoverflow.com/questions/118141/what-exactly-is-parrot