This looks like a cool idea. I think a couple of (neat!) examples, stuff you can't easily do with normal grep, will go a very long way. The list of features is secondary in my opinion.
You basically had this with the Smalltalk refactoring Browser, where each search popped up displayed in a browser window. Then you could easily AND such searches together by executing a script in the browser window. Slightly more sophisticated combinations were possible with just a few lines of scripting.
On top of that, everything above applied to syntax-driven rewrites and refactorings.
Funny, there was a bell-labs project with same name. It seems to be dead[0], but when we travel
the time a few years back, we get a wonderful project homepage[1].
It's following the illustrious Haskell tradition of barely-documented code.
(Non-snarky follow-up: Haskell code is often woefully under-documented, for whatever reason. Possibly because people think that the type signatures are sufficient, or possibly because Haskell code lends itself to concision and documentation runs counter to that, or possibly because Haskell projects are often the result of one person's work, diminishing the need to explain oneself. In any case, it's an unfortunate fact of many Haskell apps and libraries.)
Yeah, I struggled with that as well. The landing page of any software project like this should at the least have a lot of example syntax with output, plus a glaringly obvious link to full documentation.
Darn, no SQL support. I often find myself wishing something like this existed for SQL, so I could, say, find all places where field X in table Y is updated, or referenced in a WHERE clause predicate, etc.
This is aware of some basic language semantics like literals, identifiers, etc. Or so it seems. Peek at the github page https://github.com/awgn/cgrep for a little more info.
Would love a UI for this and an editor -- I still use TextWrangler/BBEdit daily to grep large chunks of source code and then edit in place (e.g. for refactoring). Just getting the search results requires opening up each file individually then editing, which is just too slow.
JSON output is incredibly useful in combination with jq[1] for processing the output. Some things become much easier than with standard *nix tools IMO.
The most reasonable explanation is that this is developed by (an) Apple user(s) and adding support for Apple's languages is simply easier and more valuable than adding languages for a platform they don't use. If it's worth it to you or other C# users, I'm sure they wouldn't mind you submitting a pull request.