Did you see this comment? kubernetes#3661 (comment). A long time ago, I saw a case where encoding a UID as an object reference like this backfired majorly, tldr because it did not line up with user-facing concept of object identity, so I'm really hesitant to recommend this.

Ah, I had seen that a few days ago but forgot. My chain of thought here was to provide some recommended structure for the applyset id, and to reserve a few values rather than setting up a format registry. I think we can recommend it separately from reserving it, but I realize this might be more than we want to do. I don't think we'd fall into the traditional drawback of UID, which is that it changes over a cluster backup and restore. If the applyset label didn't match the object ID, I think we might log a warning, but I don't think we would try to change the applyset label. We do have to do a two-step apply to use the UID though, because we can't know the UID until we apply the object, so that's not ideal.

So all that said, I'm happy to just drop uid here, we can always add it later if we need it (and I don't think we necessarily do)

Actually, in the spirit of you being an equal co-author who happens to not have push permissions, I'm going to go ahead and merge this, and we can make the decision on the "real" PR. I agree with everything else, and I'm going to think more about this one. One scenario I'm wondering about is when folks intentionally migrate from one tool to another, which we are claiming should be easier with this common foundation. Then the tool-specific naming would be undesirable right?

(as a sidenote for the id option, it would be worth mentioning any precedents for that format, e.g. kubectl get's "deployments.v1.apps", and Kustomize has something similar for GVKNN references albeit just in error messages)