It seems like the new "related query" feature is an improved version of id-only, in that it provides some semantics about the data being identified.

Should we add a blurb to the id-only section that lets the reader know that if they need to express any semantics about the id in question, they can use related query instead?

For example, if the id-only notification is about a patient merge, then there would be two references to patients, but the client wouldn't get any semantics about which is the source and which is the target of the merge.  

Or if the id-only notification is about an appointment reschedule, you'd have two references to appointments, but no semantics about which was the old v.s which was the new.

These semantics are sometimes also surfaced in the FHIR resource itself, but sometimes those semantics don't persist outside processing of the event itself.  I know I have a better example somewhere (since Appointment reschedules and patient merges can both be detected via the resources once you download those).  If I remember an example where the semantics aren't persisted I'll add that as a comment.

But anyway, my main suggestion is just adding a call out in id-only that "related query" is an alternative that provides more flexibility and lets you provide semantics for the data being referenced.