Devcontainers potentially solves the CI issue, but it does not seem to solve a problem of integrating opam with language-specific package managers. Currently using two Rust binding libraries in one binary will just explode at linking phase. See Cargo/dune integration and Cargo/Opam packaging of a Rust/OCaml project - #9 by Konstantin_Olkhovski.
At least for Rust case it would probably be helpful to automatically create local repository of Rust crates, that are coming as part of opam packages, so that when I install an opam package with Rust bits, my project build rules can use that cargo repo, generated by opam, and use specific versions of Rust crates, so that bindings work as expected.
For Python probably some other approach is required. At least some metadata in opam files should be present to encode external Python or Rust dependencies, or presence of Python or Rust source code artifacts within the opam package, so that some tools can build on top of that metadata, get the pieces of Python/Rust code to appropriate places (local repo, etc) so that they are available during build of current project/running tests.