We have been considering the following:

1. Everyone on our team at Tarides, and afaiu, all dune devs and most users, agree that having a portable way of locking dependencies is something we want eventually.
2. However, there is a lot of disagreement, and a general lack of clarity, about particulars of the implementation and design (see, e.g., this, that, or the other).
3. IMO, it is kind of obvious that it should be possible to use dune pkg without committing a lock dir in the worktree, and in fact there are many cases where users would not want to do this. E.g.,
   • See Should Cargo.lock be committed, or added to .gitignore? rust-lang/cargo#315, where Rustaceans discuss why it is common for libraries to not check in the lock directory.
   • Notice that widely used Rust libraries like thiserror, serde don't check in their lock file.
   • Recall that the vast majority or ocaml projects currently do not check in a lock file.
4. Additionally, AFAIU, the current behaviour around generation of lock directories is an aberration from the way dune usually wants to handle generated artifacts: which is to promote them from the _build directory to the worktree, and not write generated stuff directly into the worktree.
5. Since the most urgent aim with dune pkg is to provide a stable, and fully usable alternative for opam package management to ocaml developers, we don't need to solve portable locking first because this is not generally used in the ecosystem. (Pinning the opam repo already suffices for most mundane our locking needs).
6. There have been fruitful discussions recently about ways of achieving locked dependencies, without needing the noise of the full lock dir to ever be committed into the repo (cf. Lock Files Considered Harmful for an interesting related discussion!).

As a result of these considerations, we have come to the following conclusions:

1. By default, lock directories should be maintained in the _build dir and only promoted into the working directory if a user actually wants to commit it.
2. Moving lock directories into the _build dir by default allows us to unblock on the portability consideration, and move forward with a focus on the most pressing requirements for achieving stability.
3. But we still want to find and implement the optimal solution to portable package locking, and we want to keep this aim in view for the mid term.
   • A possible alternative here has been proposed by @rgrinberg, and is also discussed in the above mentioned post.

tl;dr: we think that by moving lock dirs to be in the _build directory by default, we can postpone solving that problem and prioritise other blockers preventing us from announcing dune pkg as stable. By unblocking this point, we think we can move faster towards getting useful feedback from ocaml devs based on their real usage of the tool (and possibly end up with a nicer overall design/UX experience).