This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

With my module author hat on, I definitely agree that this is a problem in need of solving - if one is developing and testing on a workspace, one can easily forget to check if each module individually still works as expected, without the workspace context.

I have a slight feeling that this feature is backwards, though. For example, right now I was using a go.work file to develop three libraries at once. When I'm done with my change, I want to make sure that each library still works as expected without go.work, and bump some dependencies for each module otherwise.

I don't think I would want to use go mod syncwork for this use case, because that feels like a very big hammer. For a library, I think it's generally saner to only update dependencies as needed. If I have libraries A and B, and A pulls a version of dependency C that's much newer than the version of C that B requires, I probably wouldn't want users of B to be forced into using the newest C unless B actually requires that - be it for a feature, or for a necessary bugfix.

I'm not sure what I would want to use instead, in terms of automation. Presumably, the right way of double checking that the library modules still work outside the workspace is a manual process. Maybe that checking, without editing any go.mod files, could be automated in cmd/go.

Nit: given https://golang.org/issue/48256 shouldn’t this be go work sync?

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

This is done.