Summary of what I observed: SurfaceFragment.annotateContent is the underpinning of most of this. Logging on it would catch use of formatting annotations and links, but not using formatting annotations without any text content -- that's done by changing the insertion annotations, not actually setting any annotation.

(If we wanted to learn things like how common it is to turn on formatting and then type, versus adding formatting to existing text, the already-existing distinction in AnnotationAction.toggle would make that really easy to log. I don't know if it matters, but it does intuitively seem like a thing which could change greatly between mobile and desktop.)

Clearing formatting via the toolbar command (or cmd-\) goes through AnnotationAction. It results in a flurry of annotateContent calls, because it individually clears each one.

Link actions use SurfaceFragment.anotateContent directly rather than going through AnnotationAction. The context item's remove-annotation button uses SurfaceFragment directly, unlike the other clear-formatting method. Setting or editing a link via the popup does an annotateContent clear and then set. Because of the live preview, opening the add-link dialog at all gets us a set, though opening it to edit an existing link doesn't.

If we log via SurfaceFragment.anotateContent, we should either filter out all the link-related actions in favor of logging attached to the inspector, or exempt link/language dialogs from the inspector logging.

That said, it's slightly more work for us in terms of places to add logging to, but I think we'd get cleaner results by logging the various AnnotationAction methods, and separately adding logging to opening the link dialog and the link context's remove-link button. Avoids the mixing up of link annotation actions with the rest of them, and doesn't overrepresent the user-action weight of things like clearing annotations from a heavily-annotated bit of text. (I.e. Neil probably has to do less data-wrangling after we've logged it.)