There's no standardisation of how to represent ownership across ABI boundaries yet, and different languages' models are fundamentally incompatible: either the VM/runtime expects to own all memory management (in which case interfacing with another VM/runtime that follows the same model is virtually impossible) or the programmer does it manually (perhaps with some help from the language in the case of C++ or Rust). Embedding a language that does the latter in a VM language is always going to involve fiddling with memory ownership in a language unsuited to it (as you do when using SWIG or the like).
What are you actually trying to achieve here? If you're writing a library for use from both VM and non-VM languages, you'll want your library functions to have clear/simple memory ownership semantics anyway, and at that point any unmanaged language will work reasonably well for you. If you just want your library to be usable from several different styles of language, maybe a multi-language VM will work for you.
What are you actually trying to achieve here? If you're writing a library for use from both VM and non-VM languages, you'll want your library functions to have clear/simple memory ownership semantics anyway, and at that point any unmanaged language will work reasonably well for you. If you just want your library to be usable from several different styles of language, maybe a multi-language VM will work for you.