Reading a little more about this. I see sending and receiving both being useful.

We add an external link in an issue. Generate a webmention to the target site
listing the issue as the source url.

Somebody on some random web site mentions an issue URL on their web site. We get a
webmention sent to:

   https://example.com/tracker/?@action=webmention

it takes the payload:

 1) verified that the target url exists/is valid (e.g.issue223 exists).
 2) GET's the source url and scrapes it looking for the target url and gathers metadata
 3) does one of two things:
    1) create a new msg of subtype webmention that will be displayed in the message
       thread (probably with different styling via css and a webmention class) with
       the metadata and maybe an excerpt/summary.
    2) create a new webmention class instance with metadata which will be
       displayed in some other section of the issue.

We will need a webmention discovery link added to the page.html template.

Also this could be (ab)used to link two trackers together. Consider an internal tracker
and an external tracker. The external tracker has conversations with customers
and a link (in a webmention_to property) to the internal tracker's matching issue.
Updates to the external tracker could become webmentions on the internal tracker.

Similarly closing/resolving a ticket on the internal tracker could result in a
webmention on the external tracker.

These wouldn't be exactly kosher webmentions as the message that updates/triggers the
webmention may not include the target URL. The target URL would be at the issue level
in a "webmention_to" property but...

This is kind of along the lines of using activity pub to federate trackers.