There have been no logic changes in recent months to my knowledge, and upstream Hound has been in maintenance-mode for a few years now.

You can try out the original Hound frontend via https://codesearch-backend.wmcloud.org/core/, to look for differences.

Both are powered by the same REST API so it should not make a difference in what results are shown. I believe the worst the frontend can do (apart from general bugs that break all results equally) is show some of the results without any/correct highighting.

Here is an example. When I try to use the (?s) modifier, e.g. in https://codesearch.wmcloud.org/core/?q=(?s)\$mSynonyms;&files=\.php$, the UI immediately claims there would be a syntax error. But this doesn't make sense because when I look at the network traffic I see a successful https://codesearch-backend.wmcloud.org/core/api/v1/search?q=(?s)\$mSynonyms;&files=\.php$&repos=* with no error. Where does the error message in the UI come from?

The old UI hangs with an endless spinner in the same situation.

When I continue this idea and add a . at the end of my pattern it doesn't match anything: https://codesearch-backend.wmcloud.org/core/api/v1/search?q=(?s)\$mSynonyms;.&files=\.php$&repos=*.

Both the Hound frontend and our own frontend use client-side JavaScript to render and highlight intraline matches in the results, which requires the pattern to be a valid RegExp in JavaScript.

The Hound backend is written in Go. I don't know if it uses the built-in Go regex, or a custom Go package, but this modifier is presumably valid there.

var x = /(?s)onoma/;
//> Uncaught SyntaxError: invalid regexp group