Creating a separate bug report from bug#49731 because this is a real problem.

Now grep.el completely supports ripgrep when 'grep-find-template'
is customized to a command line that uses 'rg' such as e.g.

  "find <D> <X> -type f <F> -print0 | sort -z | xargs -0 -e
   rg <C> -nH --no-heading -j8 --sort path -M 200 --max-columns-preview -e <R>"

But such grep setting breaks the command 'xref-find-references':

>>>> 1. while xref-find-references works fine in `emacs -Q`,
>>>> I don't know why with my customization typing e.g.
>>>> 'M-? isearch-lazy-highlight RET' reports
>>>> "No references found for: isearch-lazy-highlight".
>>>
>>> Try and see which of the "tools" semantic-symref-perform-search ends
>>> up using.
>>
>> Thanks for the pointers to semantic-symref-perform-search.
>> It prepends "-n " to my customized pattern "rg -nH",
>> so the arg "-n" is duplicated on the command line:
>>    `rg -n -nH`
>> and signals the error:
>>    error: The argument '--line-number' was provided more than once, but
>> cannot be used multiple times
>> This error is caused by the bug in the command line parser used by
>> ripgrep:
>>    https://github.com/clap-rs/clap/issues/2171
>> that was fixed only 6 months ago, so it will take much time
>> before this fix will reach ripgrep, and this bug will be closed:
>>    https://github.com/BurntSushi/ripgrep/issues/1701
>
> The above might be worked around with creating a symref-grep specific user
> option for grep-find-template which would default to the "global" value of
> that variable.

Maybe like the existing option 'semantic-symref-grep-shell', e.g.:

  (defcustom semantic-symref-grep-program 'grep
    "The program to use for regexp search inside files."
    :type `(choice
            (const :tag "Use Grep" grep)
            (const :tag "Use ripgrep" ripgrep)
            (symbol :tag "User defined"))
    :version "28.1")

But the problem is that for users it's hard to see the connection
between the broken 'xref-find-references' and the need to customize an option
with unrelated name 'semantic-symref-grep'.

>> But even without duplicated "-n" semantic-symref-perform-search
>> doesn't work with ripgrep because it doesn't find such pattern:
>>    \\\\\\(\\^\\\\\\|\\\\W\\\\\\)isearch-lazy-highlight\\\\\\(\\\\W\\\\\\|\\$\\\\\\)
>> Maybe semantic-symref-perform-search could be improved to
>> support ripgrep?
>> Because without these two problems it works fine with ripgrep.
>
> ...but the above tells us (I think) that semantic-symref-perform-search is
> trying to use the basic regexp syntax, and ripgrep doesn't support that
> (only Extended, or PCRE).
>
> For your personal consumption, perhaps the best approach is to create
> a separate "tool", like Grep (by copying symref/grep.el and tweaking some
> of its definitions), and then register it in semantic-symref-tool-alist.
>
> I don't know if ripgrep is that much faster for this particular purpose. So
> maybe it's too much work for little benefit.

A more general solution would be to add to grep.el the same options
that you added to xref:

  xref-search-program grep/ripgrep
  xref-search-program-alist
    '((grep . "xargs -0 grep <C> -snHE -e <R>")
      (ripgrep . "xargs -0 rg <C> -nH --no-messages -g '!*/' -e <R> | sort -t: -k1,1 -k2n,2"))

This means to turn the existing variable 'grep-program' into the user option
as the following patch does.

Also later grep.el could use the value "rg" of 'grep-program'
to create the corresponding grep-find-template in grep-compute-defaults.

But I don't know if it's ok to mention rigrep in grep.el?

Anyway, here is the patch that fixes 'xref-find-references':