als hättest du es geschafft die Funktionalität simpler und effektiver umzusetzen als bei meiner JSON_Get.
Danke für die Blumen - aber nicht wirklich. 
_JSON_Query ist quasi _JSON_Get mit der Möglichkeit statt Indizes Bedingungen für die Arrays zu übergeben.
Im Prinzip mache ich nur Folgendes:
• sind Bedingungen in den Array-Pattern enthalten?
wenn nein: Return _JSON_Get mit dem übergebenen Pattern (Man braucht also _JSON_Get nicht mehr aufrufen, macht _JSON_Query sowieso)
wenn ja:
• erste Arrayposition mit Bedingung im Pattern suchen
• den Teil des Patterns davor (repräsentiert das Array) mit _JSON_Get abfragen - liefert das Array
• durch dieses Array iterieren und vergleichen ob der Schlüssel an der Indexposition den Wert aus der Bedingung liefert - wenn ja: das ist der gesuchte Index
• im Ausgangspattern die Bedingung mit dem gefundenen Index ersetzen
• das Ganze wiederholen bis keine Bedingung mehr gefunden wird
Jetzt enthält das Pattern statt der Bedingungen die zugehörigen Indizes.
Mit diesem Pattern rufe ich jetzt _JSON_Get auf
Ich würde diesen Denkansatz spontan gerne verwenden um die JSON_Get-Syntax, nach deiner Zustimmung, um eine Filterfähigkeit zu erweitern, anstatt eine Extra-Funktion mit hinzuzufügen (Credits natürlich entsprechend anpassen).
Kannst Du gerne tun.
Im Grunde überlege ich auch die Funktion namentlich von JSON zu trennen, da die Funktion JSON_Get als auch deine JSON_Query() eigentlich gar nicht auf JSON beschränkt ist sondern allgemein verschachtelte AutoIt-Strukturen behandeln kann.
Da ist was dran. Ich hatte auch schon überlegt, wie ich das SQL-ähnlich gestalten kann, um auch komplex Filtern zu können, z.B. aus einer JSON / einer Map / einem Array ... mit Personendaten (sagen wir mal: "Name", "Vorname", "Geschlecht", "Alter", "PLZ", "Ort", "Strasse", "Nr", "Beruf", "Jahreseinkommen") wollen wir alle Männer unter 40 mit einem jährl. Einkommen von XYZ im PLZ-Gebiet 10... abfragen. Wir können also zwischen 0 und n Ergebnisse bekommen - das Ergebnis dann wiederum in einer brauchbaren Form ausgeben (enumeriertes Array, Map, Dictionary...).
Die Syntax kann man tatsächlich extrem zusammenstreichen:
select - braucht man nicht, ist das einzige Ziel beim Filtern
fields - ja, das muss sein
from table - braucht man auch nicht, ist immer rückbezüglich auf die Position im Pattern
where - das Schlüsselwort ist auch unnütz, na klar kommen nun die Bedingungen
conditions - genau, das brauchen wir
Bleibt nur die Gestaltung der Operatoren, da liebäugele ich mit den C++/Phyton Operatoren: and = &&, or = Doppelte-Pipe (wird vom Editor als Smiley gezeigt), not = !. (Symbole sind m.M.n. einfacher/eindeutiger zu Parsen, als Worte). Zusätzlich natürlich: < = > und auch contains - wobei ich dafür wiederum auch ein Symbol verwenden würde, vielleicht: ?
Damit sollten eigentlich wesentliche Filteroperationen möglich sein. Es wird sicher nur etwas aufwändig, die Auswertelogik zu gestalten (Berücksichtigung aller Klammerausdrücke, Rangfolge der Operatoren). Aber es hat ja auch keiner behauptet, dass sowas ein Spaziergang sei. 
)
Leichenschänder
. Meinungen sind absolut und müssen erst mal kräftig postuliert werden. Am Besten mit einem Schuss Provokation versehen. Aber glaub mir, wenn dir Andy im Biergarten gegenüber säße, würde er sagen: "Das ging nicht gegen dich als Person, aber ich schieße mit breitem Streufeuer und du standest nun mal gerade im Weg."