workspace: protocol vs. version range for managing internal dependency patches

When maintaining a pnpm workspace that contains an internal package consumed by other workspace projects, teams must decide whether to reference that internal package via the workspace: protocol (e.g., "workspace:^1.0.0") or via a semantic version range (e.g., "^1.0.0") in the dependent manifests.

The goal is to receive security and bug fixes published to the internal package’s registry version without introducing version drift that could break API compatibility across the workspace.

Using the workspace: protocol guarantees a single, exact instance of the internal package but blocks automatic patch propagation unless the source package version is bumped; specifying a version range lets pnpm pull newer compatible patches but risks different workspace projects resolving to different versions if their ranges diverge.

How should a team weigh the trade‑off between guaranteed consistency and automatic patch uptake when the lockfile does not capture the reasoning behind the chosen approach?

What verification steps can confirm that the selected method yields the desired balance of patch propagation and workspace‑wide version uniformity?