nimble.lock in Library Repositories: Should the Lock File Be Committed After Upgrading to a Nimble Version That Supports It?

Our Nim project recently moved to a toolchain whose Nimble version supports the nimble lock command and honors nimble.lock during nimble install. The repository is a library published to the Nimble package list, not a deployable application, and we need to decide whether the lock file belongs in version control.

The tension we see: committing nimble.lock pins exact dependency versions and VCS revisions, which makes CI runs and contributor checkouts reproducible. But the same pinning could mask compatibility drift, since our declared version ranges in the .nimble file would keep resolving against old locked revisions while downstream users get whatever the solver picks fresh. Deleting the lock before release testing is one option, but that reintroduces non-determinism into the exact pipeline we wanted to stabilize.

We have not found documented guidance in Nimble itself distinguishing library versus application lock-file policy, and solver behavior has changed across releases, so we want to pin this down for our specific Nimble version.

1. Is committing nimble.lock in a published library repository considered harmful for downstream resolution, or does Nimble ignore a dependency's own lock file when it is consumed as a package?
2. If the lock is committed, what is the recommended workflow for periodically testing against the newest allowed dependency versions within our declared ranges?
3. Does the answer change if the same repository also ships a binary built via a Nimble task?