All true, but I think @xavierleroy fairly characterizes the concerns registered here in this thread by the following message posted on another thread:
What is at issue here is not really about making simple things easy, which I think we all agree opam and dune taken together do a decent job with today, but rather with ensuring the complex things remain possible, which would be at risk if dune and opam were merged into a unified tool with only the opaque library interfaces between them in regular maintenance.
I think everyone should want dune to be usable with whatever alternatives to opam that project developers want to target, e.g. nix, FreeBSD pkg, Ubuntu apt, et cetera. Likewise, I think everyone should want opam to be usable with whatever alternatives to dune that application packagers what to use, e.g. make, bazel, b0, et cetera.
As Xavier suggests, it should not be a problem to experiment in developing something that provides a unified CLI capable of driving both opam and dune together. The problem would arise if the opam and dune tools were to stop being usable independently because only their core libraries were actively maintained as parts of the unified driver tool, while the other CLI tools were left to decay.
Accordingly, it’s a bit of a problem to position the experiment to develop a new addition to the software ecology as an effort to simplify the language toolset, unless you’re going to be explicit about abandoning the parts of the ecology that the new addition is meant to make obsolete.