drom is a tool by @lefessan. nopam is a codename I just made up to illustrate the difference between current opam and a hypothetical new client.
None of these are opam 3. When we flush through our opam 2.x stack (notably Windows support and other feature specs), we’ll publish a roadmap for opam 3. My point was that we encourage experimentation outside the critical path of opam releases, and the opam dev team will gather and internalise all the data we have available when it comes to setting the direction for opam 3 and onwards. If you do experiment, and you do post here, your efforts will not be forgotten.
I take no position on your normality, @jjb 
The only problem with the “edit opam first” workflow is simply not having feedback on whether or not the solution of packages and dependencies actually works for you. For instance, if I edit the opam file to depend on a package that conflicts with a current one (or introduces a dependency cone I dont like, or something else), then the solver needs to run to show that to me somehow. That works today since opam install shows you that action graph, but something else needs to be receiving these requests with an alternative client.
Many of our platform tools are adding RPC support at present due to this need for more interactive feedback with modern IDEs – dune, ocamlformat and merlin all have that now, and you can already observe the benefits with merlin directly talking to dune for example. It may make sense for ocaml-lsp-server to become the unified process behind which all the other tools sit, and for a CLI tool to also communicate with a daemonised process tied to a project (just as VSCode does today).