Should --crlf change dot matching behavior?

[Simran-B]

--crlf
When enabled, ripgrep will treat CRLF ('\r\n') as a line terminator instead
of just '\n'.

However, the option description goes on and limits this to $:

Principally, this permits '$' in regex patterns to match just before CRLF
instead of just before LF. The underlying regex engine may not support this
natively, so ripgrep will translate all instances of '$' to '(?:\r??$)'. This
may produce slightly different than desired match offsets. It is intended as a
work-around until the regex engine supports this natively.

I wonder if the option should change the behavior of ., which matches any character except \n (unless --multiline-dotall is used).
In CRLF (Window line break) mode, it would potentially make sense to let . match any character except \n and \r (or maybe only \r?\n).

Context: microsoft/vscode#87247 (comment)

[BurntSushi]

This is tracked by rust-lang/regex#244 --- And indeed, the last few comments talk about what . should do. The only real choice I think is to make it equivalent to [^\r\n] when CRLF mode is enabled. Other options are not really compatible with the regex engine. (And indeed, the plan for $ in CRLF mode is for it to treat \r and \n each as line endings, but \r\n as one single line ending. Ideally we wouldn't treat a lone \r as a line ending---the days of macOS using that convention are long past us---but it is too difficult to do otherwise in the regex engine.)

I would somewhat rather we wait until CRLF support lands in the regex engine for this, but it could be some time before that happens. If someone wanted to submit a patch to ripgrep that rewrites . as [^\r\n] when --crlf is enabled, I would be okay with that. The change should be entirely isolated to crates/regex.