Carbon pointer safety rules when passing objects across the C++ interop boundary

Context

I am evaluating Carbon (the experimental C++ successor language) for a gradual migration of an existing C++ codebase. The design goal under review is how Carbon's memory-safety model interacts with its bidirectional C++ interoperability, specifically when ownership of an object crosses the language boundary.

Uncertainty

Carbon aims to reduce classic C++ pitfalls such as use-after-free, but it also promises seamless calls into C++ functions that may take raw pointers or references. It is unclear to me which safety guarantees survive that handoff: if a Carbon object is passed to a C++ function that stores the pointer beyond the call, does the Carbon side still track or constrain that lifetime, or is the safety model effectively suspended at the boundary? I also cannot tell from the high-level documentation whether Carbon distinguishes pointer types (owning vs. non-owning) in a way the compiler can enforce during interop, or whether enforcement relies on convention.

Because the language is experimental and the specification changes frequently, I am assuming a recent toolchain snapshot rather than any stabilized release.

Questions

• Does Carbon's current design specify lifetime or ownership rules for pointers handed to C++ code, and are any of them compiler-enforced?
• Is there a documented annotation or type-level distinction for unsafe/interop pointers versus safe Carbon references?
• Are the interop safety guarantees tied to a particular C++ standard or ABI version?