Thank you @gasche for your interest and input!
Expanding on what @rgrinberg and @rjbou mentioned earlier, there are no intentions to phase out the opam client. As a matter of fact, the Dune team has currently forked opam and is patching the opam libraries, with the ultimate goal of merging them back upstream once the libraries exposing the necessary APIs for Dune package management appear to be stable. You can see some of this work in progress in pull requests like #5568, #5508, #5498, #5496, #5452, and so on.
As for the opam repository, you understood correctly that there is absolutely no plan to deprecate it, or even to make large changes to it in the context of Dune package management. The goal is for Dune package management to be 100% compatible with the opam repository.
To expand on a slightly divergent path and talk about the role of the OCaml Platform: the Platform essentially mirrors the state of the world. For the opam client to become deprecated in the Platform, it would need to become the de-facto reality first. While it might be that the opam client (as for any other tool) enters a maintenance mode and eventually becomes deprecated, that seems unlikely for now, given the number of users who are relying on the opam client. That being said, if and when that happens, the Platform’s role will be to make sure that there is a smooth transition path for users, and that’s something that will require careful planning and discussions. All of which is entirely out of scope for the initial release of package management in Dune.
On a different note, following a discussion with @dra27, opam switches are architected around findlib/ocamlfind. Dune package management presents an alternative solution to achieve the same result. As you point out, it’s not meant to be reusable between workflows: the opam packages Dune compiles for your project are intended for Dune’s internal use during its build, not for external use with the shell. This could be viewed as a parallel to how opam builds switches for opam exec (with eval $(opam env) serving as a convenient shortcut). So, you can think of Dune package management as performing a similar function but specifically for dune exec.
Now, there is the question of how to make sure this doesn’t create confusion and hurt adoption.
But that’s not something that’s specific to Dune and opam. In fact, if anything else, it makes the Platform more cohesive: odoc, ocamlformat, merlin, utop and mdx are all tools that work well independently, but with which you don’t need to interact if you use Dune. Dune has grown as the frontend of the Platfrom and the integration with opam is another step in this direction, not something very new if we look at what’s being done with the other tools.
And this is the best of both worlds: as a power user, you’re free to use each tool independently and you’re not locked in, but as a newcomer or even as a power user who’s happy with the default experience, you can just use Dune.