cc @bcmills

Is this related to #59480?

No I don't believe so. Here, you are entering that submodule and doing ./... inside that. And this is very specifically related to the presence of a go.work file. Without the go.work file, everything works fine.

So in public, you're in a module, it's a subdirectory under a workspace, but the module isn't listed in go.work.

~/tmp/testrepo0172/modbug/public/model 0:00:00
master » go build     
main module (github.com/agnivade/modbug/v7) does not contain package github.com/agnivade/modbug/v7/public/model

I believe workspace has higher priority than the module, which is why it reports the main module to be the one rooted in the workspace directory (module github.com/agnivade/modbug/v7) and not the one in the nearest parent (module github.com/agnivade/modbug/public/v7).
With that view, the local package can't be part of the main module, because there's still a go.mod carving out a module starting at public.

Sounds like go is inferring the package name for . using just the workspace, which excludes the nearest go.mod.
But giving it the full name works, because it matches via the replaced dependency from the module in the workspace root.

#49632 #51604 are probably related but simpler cases

Yes, there is a difference between ./... and <package_path>/....

I need to check if adding use ./public in go.work fixes the issue.

Aha! That fixed it. Sorry for the noise. No bug here. But rather a slightly misleading error perhaps.