One thing I realized after putting up this PR, though, is that adding the markers to the nodes isn’t sufficient for our use-case, because we support installing from multiple different “roots” in the lockfile (because we support “workspaces”, groups of local packages that depend on one another).
With uv, you could have a lockfile that includes both local package A and local package B, which may not depend on one another (they can, though – A could depend on B, etc.). And you can install just A and its dependencies, or just B and its dependencies (uv sync --package A vs. uv sync --package B, from the same lockfile). So to support that, you can’t have a flat list of packages with markers that tell you when to install them, since A could depend on C with sys_platform == 'win32' while B depends on C with sys_platform == 'darwin'. The “combined” marker would be sys_platform == 'win32' or sys_platform == 'darwin'… But you don’t want to always install C on those platforms – it depends on whether the user request the dependency tree rooted at A or B.
So, from that perspective, the markers kind of represent… the superset of platforms on which the package might be installed? Like, C would never be installed on platforms other than win32 or darwin, but it wouldn’t be installed on win32 unconditionally.
As long as we (uv) want to support this, I think we need to track markers on edges, not nodes. (I don’t have a strong objection to including them on the nodes, but we wouldn’t use those markers for anything.)