@isaacs/nested-yarn-lock-test

This is an example case showing that a yarn.lock file does not guarantee package resolutions at all levels.

root (x@1.x, y@1.x, z@1.x) <-- 1.x dep here
+-- x 1.2.0                <-- 1.x resolves to 1.2.0
+-- y (x@1.1, z@2.x)
|   +-- x 1.1.0            <-- 1.x resolves to 1.1.0
|   +-- z 2.0.0 (x@1.x)    <-- 1.x dep here
+-- z 1.0.0

Both Yarn and npm create the same folder structure in node_modules, which is good. But the yarn.lock file indicates that x@1.x should resolve to version 1.2.0, and z@2.0.0's dependency on x@1.x resolves to 1.1.0 instead.

Conclusion: yarn.lock on its own does not guarantee resolutions or deterministic builds. That part of the contract is provided by the implementation of Yarn itself, not in the lockfile format.