Confusion around ODB/mempack lifetimes

I have some code like this in a function:

repo.odb()
            .context("Failed to get the repo's object database")
            .unwrap()
            .add_new_mempack_backend(999)
            .context("Failed to create new mempack ODB backend")
            .unwrap();

So I'm immediately dropping the returned Odb. I had trouble understanding the underlying C code in libgit2, so my first question is:

Assuming I never explicitly set an alternative ODB, should repeated calls to repo.odb() ultimately point to the same underlying resource in "C land"?

Secondly, I've observed that if I create a mempack backend like this and then write things to the repository (trees, blobs) then most of the time they never get written to disk (good) but occasionally they do (intermittent, bad!)

So my next question is:

Is there an obvious explanation for this — e.g. am I supposed to be keeping the Odb alive to stop the mempack backend from (eventually?) being removed/destroyed?

I'm hoping I've just misunderstood something simple about mempack usage. 🙏

Thanks!

Start by tracing the issue's repo.odb() and add_new_mempack_backend(999) calls through the Rust bindings and the underlying libgit2 behavior. Reproduce repeated ODB access and repository writes, then determine whether dropping the returned ODB affects the mempack backend and whether the observed disk writes are expected.