Ugh, fudging $$cc to accomodate a kludge... ugliness.  No, the original regex situation must be solved.  And I think it has been.  I gave it some more thought, and here is the proper solution, or at least on way to do it cleanly:

^tor(?:rent)? ((?:[^-]|-(?!-))*)(?:\s*--\s*(.*))?()



Yes, it's hairy, but does things properly.

Explanation:

^tor(?:rent)?
    Same as before.

((?:[^-]|-(?!-))*)
    Capture group $$1: capture as many characters as possible, as long as they are not a dash, or a dash followed by anything other than a second dash.  The outer "()" pair does the capturing/extraction.  The inner "(?: ...)" is there to limit extent of "|", without capturing.  The "(?!-)" is a negative look-ahead: matches when next character is not a dash, but does not consume it.

(?:\s*--\s*(.*))?
    Capture group $$2.  The outer "(?: ....)" groups the expression without capturing.  The trailing "?" makes the whole chunk optional.  The "\s*" are there to strip any white space, although the first instance is futile (the previous capture group will gobble up its trailing white space... regex parsing is greedy).  The inner "(.*)" is the part that actually does the capturing/extraction of $$2.

the trailing ()
    This again was needed, in the case where "--" is not given on the command line.  In such cases $$2 does not exist, hence the "$$2" in the "Result Filter for RegEx" field is being treated as a literal string, rather than a variable.  This causes 0 matching results, unless one of the result hits contains a literal (unsubstituted) "$$2" string.

So with this regex you can go back to using $$1 instead of $$1$$3.

Hope this helps.

Drat, I cannot make either of the scripts work, it seems.  I don't know why.  I even removed #IfWinActive selection, and mapped to left Alt, and still nothing happens.  nitrix, I take it those scripts worked for you, right? Odd...

EDIT: Ah, found the culprit.  At least on my system, I have to use

WinSet, Transparent, <value>, A

to point at the currently active window.  Without it, it refers to Last Found Window, which apparently is not set by anything in the scripts so far (according to docs).

Really?  Too bad, would have been useful.  I assume that by overhead you mean the need to store for each result item the full scouring source information and such.  But perhaps when "show score break-down" is clicked, the search can be *rerun*, and as it progresses this time around the more expensive code path is chosen, the one which notes all the details.  That way things would be fast and lean during normal operation, as usual, and the extra load is only incurred on an introspective run through the search...  Just a thought; in all likelihood this approach is not even viable, I don't really know what the control flow of FARR is during its searches.  But hey, I can wish. :)