So, after tinkering with it a bit under the assumption that the asterisk cannot be used within the path component of a url, here's some additional findings:
- Multiple asterisks used by a single pattern (that match against the domain component of a url) appear to be consolidated into one asterisk. (i.e.
*.*.*.comwill include results from *.com)
- The asterisk seems to only produce results if it's used as a domain component (i.e.
blog.*.com and not blog.k*gi.com)
- The asterisk seems to only match against a certain number of characters within the component (i.e.
*.co will not match t.co).
- Asterisks that wrap the domain seem to query the index....differently? (i.e.
*.example.* does not match www.example.net, www.example.com, or www.example.org). Although, this test could be a search-quality issue (unrelated to asterisks), because you could be indexing redirects by their target url.
In order to test, I had to go through the full process of recreating the lens as opposed to simply editing it as it appeared that the lens would take a minute to recognize my changes. This correlates with the symptom produced in the original report. In retrospect, it probably would've been better to create a proper environment and script the creation of the lens in order to simplify said testing.
I also had some issues trying to come up with domains that kagi might've indexed which also met the constraints that I was trying to test...sort of like an EICAR (used by AntiVirus), but for search. The example.org, example.net, example.com provides multiple TLDs which kagi appears to have indexed. Single-letter domains, though, (usually used by url-shorteners) don't seem to be used enough to have been indexed. Hence, I was only able to use t.co (since people tend to link that domain). I also did not bother testing homographs or puny-code encoded domains as it seems that those are presently indexed by kagi in their encoded form.
Anyways, hopefully this helps provide more clarity on the issues being encountered within lenses.
