I think we can just do {PHID-...}, not {{PHID-...}}. It isn't ambiguous with {T123}, etc.

It would maybe even be OK to mark up plain PHID-... in the future, although I don't like changing the text when the reference might be ambiguous. But we could have these still say PHID-... and at least produce hovercards, which would be a little better in all cases and worse in none, I think.

Maybe make the PHID-capturing part a little stricter, like [^\s}] (i.e., prevent whitespace). I think this could capture a whole paragraph if you type like:

{{PHID- is how you start a PHID reference and then you end it with }}

...which isn't the most faithful rendering of the original input text.

Because the pattern is liberal, we should have an if (!$this->isFlatText($matches[0])) check here which just returns $matches[0] for non-flat text.

This prevents shenanigans like {{PHID-**x**}}, where you put rich text inside the rule. In some cases, this can lead to security issues in the generated markup.

I think we should also do a phid_get_type() here and just return $matches[0] if the pattern doesn't have a type or, ideally, if we don't recognize the type. That is, when the user types:

{{PHID-x}}

...the best rendering is just their input text, not "Unknown Object (???)", since that could make a log or table or example which means to include this text as raw text unreadable and confusing.

HandleQuery should always produce a handle, even if the PHID is nonsensical or invalid, so this check might be impossible to miss.

A better check might be !$handle->isComplete(), which indicates that the handle is inaccessible or not really referencing valid object.

I think you can setPHID() on $link to get a hovercard (which seems like a good/reasonable behavior to me).