The Word That Covers Two Opposite Products
The previous track refused a package. This track accepts one. If those two sentences use the word the same way, one of the tracks is lying.
They do not. A published package is a product sold to consumers you do not control: it lives on a registry, it carries a version, it is fetched at install time, and two consumers pinning different versions is a supported state. That is the isolation product. That is what the family declined, and still declines, for every language.
A path package is a compiler instruction. It says: build the package in this directory beside me, from whatever the directory holds right now, and let me link the products I name. Its targets are still separate modules; what the path removes is the version, not the module boundaries. There is no version. There is no publish step. There is no registry account. The directory is the sibling working tree the family already lives in. Resolving it costs what vendoring costs to set up — a line in a manifest the consumer already had — and nothing to keep.
What Isolation Would Have Added Here
Walk the published-package charges against this family and they are still charges, not features. A publish step in every Swift change. A version number that has to be reasoned about and bumped. The possibility — now made legitimate — of two phone apps compiling different revisions of the shared types. The last one is the same sharp edge the original record named: skew as a supported feature, inside the repository that exists to make skew a bug.
A path dependency cannot express that skew as a choice. It points at a tree, not at a tag, so there is no line in which one consumer asks to stay on an older revision. Two builds on different days can still compile different trees, because the directory moved between them — the last lesson of this track is about exactly that cost — but no consumer can decide to stay behind. That is not a limitation the family is patiently enduring. It is the property they were buying.
Still No Registry
The previous track's spine doctrine looked, for a moment, like a casualty: a consumer now lists a package. Read the list. The package is a relative path to a sibling that is already on the machine. A cold checkout of the consumer alone can no longer build the Swift half. That part is new, and the previous track's third lesson says so: the vendored half still builds from the consumer's checkout alone, while the Swift half now needs the kit beside it. What made the trade acceptable is that the kit repository was already a sibling the family layout assumed, and the drift check already depended on it. (Where that sibling is missing, the check now fails on a fleet Mac and skips only off the fleet; track 4.) The path package did not add a network. It named a directory the family layout already assumed.
What would break the spine is a registry. A tag. A promise that the bytes can be fetched later. None of those arrived. The next lesson is why the compiler needed to see the graph at all; this one is only the refusal to misname it.