I mean speed is nice, but it is not the primary thing I am concerned with in a search engine, as long as it is acceptable it is not in the list of requirements - things that would be on my list - not necessarily in this order but close

1. What human languages does it support.

2. In these human languages how does stemming and decompounding work in your implementation.

3. how is word importance determined in your index - TF-IDF? other algorithm? Are least important words automatically dropped from queries?

4. Do you have ability to rank on both the stemmed/decompounded query/results and exact matches? So something like raw field access.

5. Can I create my own semantics - I remember seeing a post on here recently where someone had created a search engine (in Rust I think) that was faster than ElasticSearch but from what I could see you couldn't create your own field names so you were stuck searching in title, description, body, creationDate and a couple other fields which really decreases the usefulness.

I mean these are the things that right away spring to mind to ask about when someone tells me they have a new search engine, and when they show me look at my speed benchmarks I'm thinking "what am I supposed to do with this?"

on edit: formatting

on second edit: So I guess as in most things I am interested in how the product actually fulfills what should be its primary functionality, so how does the search engine function as a search engine, I suppose my questions could be answered with quick - our search engine has feature parity with ElasticSearch / Solr where features A, B, and C are concerned - features D and E will be supported in the future.