Quoting my message from Slack.

This was a long discussion when we first discussed how to do observe-only resources, i.e. whether it should be an annotation/policy field or a separate kind. Where we sort of landed was a separate kind with data field instead of spec because ultimately, the fact that user wants it to be observe-only or paused overrides their desire of how the resource should look like but it is still confusing to have a spec that is simply ignored. This was the main thing that moved the needle towards a separate kind for me even if that solution requires much more effort.

There is a conceptual race there about whether the desire is spec or the annotation when both exist. I’d personally approach from another angle as well which is the fact that we set Synced to False only if the reconciliation doesn’t succeed and in the reconcilers we made the decision that annotation is the final desired state if given (we return if we see it). From that perspective, I think we already made a decision in the reconciler about which field has the final say so I think setting Synced to True would be inline with that. So I suggest we set it True.

Intuitively Synced=False seems correct to me. A resource that is paused may not not have its desired state synced, and a resource that is experiencing a reconcile error may not have its desired state synced. They're two different reasons that a resource may not be in sync.

there were some concerns around how the paused state of a managed resource is communicated.

Could you state explicitly what the concerns are?

I'm not sure how much we can really change at this point - I would consider status conditions as part of a resource's API and thus changing the status conditions (with perhaps the exception of the human readable message) to be a breaking API change.

That said, I think observedGeneration would probably do a better job of communicating what the synced status currently tries to communicate. From https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md#conditions:

If the controller is not running, or for some reason not able to update the resource, it will look like it is in a good state when that is not true. The solution to this issue is to adopt the pattern used by several of the built-in types where there is an observedGeneration property on the status object which is set by the controller during the reconcile loop. If the generation and the observedGeneration of a resource does not match, it means there are changes that the controller has not yet seen, and therefore not acted upon.