Inconsistent assumptions over interface when additional copy of library is present in vendored_dirs

It all started with the following dune build error (dune verbose output showed linking command with a lot of .cmxa passed to ocamlopt):

$ dune build
File "_none_", line 1:                 
Error: Files /home/user/git/ocaml/my-project/_opam/lib/foo/cloud/foo_cloud.cmxa
       and /home/user/git/ocaml/my-project/_opam/lib/rust-errors/rust_errors.cmxa
       make inconsistent assumptions over interface Rust_errors__

While searching for other possible occurences of Rust_errors.ml in _opam, I noticed these:

_opam/.opam-switch/sources/foo.1.2.3/vendor/ocaml-rust-errors/lib/Rust_errors.ml
_opam/.opam-switch/sources/foo.1.2.3/vendor/ocaml-rust-errors/lib/Rust_errors.mli

Turned out vendor was marked as vendored_dirs in foo lib, and latest changes introduced vendored Rust sources (Cargo is using vendor dir by default), which in turn had OCaml bits in corresponding repositories that Cargo distributed along with the Rust sources. I changed that to data_only_dirs and the inconsistent assumptions error disappeared.

I assumed that Dune should just ignore vendored bits when libs are properly installed and used via opam. Vendored version of Rust_errors__ creeped somehow into final .cmxa?

I know this issue is far from minimal reproducible test case, and likely not really actionable, but I'm still posting it here in case it rings the bell for someone in the Dune team, or maybe someone finds this issue while stumbling upon inconsistent assumptions error and my workaround would be applicable for them.

Specifications

• Version of dune (output of dune --version): 3.12.2
• Version of ocaml (output of ocamlc --version): 4.14.0
• Operating system (distribution and version): Debian GNU/Linux 11 (bullseye)

Start with the reported verbose dune build command and the interaction between vendored_dirs and data_only_dirs in the foo package. Compare the installed foo_cloud.cmxa and rust_errors.cmxa with the vendored Rust_errors.ml and Rust_errors.mli, using Dune 3.12.2 and OCaml 4.14.0 if reproducing. Done means establishing whether vendored OCaml sources can enter the linked library or documenting the confirmed workaround.