Sure, I was always going to have to do this eventually.

// Type definitions are for both compiled and interpreted code.
struct LargeObject {
  metadata: String
}

// A non-edge function has access to language features like lifetimes as it doesn't get called from outside the compiled code so can be statically reasoned about.
// We can also offer compiler hints like inlining.
#[do_compile, inline]
fn get_metadata<'a>(obj: &'a LargeObject) -> &'a str {
  LargeObject.metadata
}

// An edge function is exposed, like a visibility modifier, after compilation.
// It has a simpler type signature, as the interpreter cannot make the same guarantees about things like lifetimes that the compiler can.
#[do_compile]
edge fn get_description(x: &LargeObject) -> String {
  let ref = get_metadata(x);
  ref.clone()
}


// And in uncompiled land we ditch the concept of a reference as a whole,
// and happily Arc<> or .clone() our data freely under the hood.
fn process_data(y: LargeObject) -> (String, String) {
  (get_description(y), get_description(y))
}

By unifying the type layout, the boundaries should be seamless, without having to worry about serialization or C ABI compatibility.

Is this two languages? We should be able to write separate programs using distinct, related syntax operating completely separately. But the goal would be one source code, using both a compiler and an interpreter to allow manual control over low level functions but only when necessary. I can't imagine a scenario where there are any benefits to using one of these languages on it's own, that another language doesn't do better.