Nimble lockfile ignored when global package satisfies version range

Nimble records exact resolved dependency versions in a nimble.lock file, but by default it installs packages into a shared user-global directory rather than a project-local environment. When a globally installed package already satisfies a project's version range yet differs from the locked version, it is unclear whether Nimble reuses the global copy or enforces the lockfile, which can silently alter build inputs across machines.

Lockfile semantics and dependency path resolution have shifted across Nimble releases, so behavior observed in older tutorials may not apply to current versions and should be checked against the installed Nimble release. Nimble also lacks native support for pinning the Nim compiler version or sandboxing builds, making repeatable toolchains dependent on external wrappers or manual path management.

What is the documented resolution order when a global package conflicts with a nimble.lock entry, and does Nimble offer a supported flag or configuration to force per-project isolation from the global cache?