Is het verklaarbaar dat de volgende zoekopdrachten leveren verschillende resultaten opleveren?
Geven verschillende resultaten voor mijn adres. De “suggest” geeft de juiste lokatie maar de “free” komt met een tamelijk onlogische plek (ergens bij Deventer). Ik zou verwachten dat hetzelfde algoritme het resultaat bepaalt.
Mag ik hier nog even bij opmerken dat voor het gebruik in eenvoudige ‘geocoder’-widgets in de gemiddelde web-app of in QGIS eigenlijk de ‘suggest’ output al voldoende zou zijn MITS(!) daar dan ook een x en y bij zouden zitten.
Ik dacht eerder te hebben vernomen van @fsteggink dat dat technisch eigenlijk vrij eenvoudig zou zijn.
Als die x en y nameljik al in het eerste suggest-result zitten, is de tweede roundtrip naar de ‘lookup’ service optioneel maken.
En in het geval van @raymondnijssen zou hij dus gewoon de suggest kunnen gebruiken 
Verschillende factoren spelen een rol. Als basis wordt Apache Solr gebruikt. Er zijn ontzettend veel manieren om Solr te configureren, dus het is best een uitdaging om Solr als een geocoder te gebruiken. De suggest en free endpoints zijn op andere manieren geconfigureerd.
De grootste factor is dat de woonplaats Den Bosch in de BAG 's-Hertogenbosch heet. Dit is als synoniem opgenomen. Er is nu toevallig een exacte match met een straat elders. Als je rows=100 toevoegt, zie je op een gegeven moment wel de Fahrenheitstraat in Den Bosch (als straat, niet het adres), maar die staat tussen een aantal andere Fahrenheitstraten. Vreemd genoeg ook niet bij een eerdere “batch” met Fahrenheitstraten. Ik heb hier geen verklaring voor.
Het feit dat wegen (en woonplaatsen) hoger scoren dan adressen heeft er mee te maken dat die standaard een hoger gewicht hebben. Bij de suggest wordt dit overruled door het gebruik van exacte matches op bepaalde velden, zoals straatnaam en huisnummer bij adres, maar bij de free service niet.
Als je aan je query string &debug=true toevoegt, wordt een hoop extra informatie meegegeven, waaronder de manier waarop Solr de score berekend heeft.
Als je zoekt met 's-Hertogenbosch, dan zie je dat de weg Fahrenheitstraat in Den Bosch als eerste wordt teruggegeven: https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?rows=1&q=fahrenheitstraat%201,%20’s-hertogenbosch
Het adres komt pas als tweede. Dit heeft met het gewicht te maken. Als je weet dat je op adressen zoekt, kun je het beste een filter query meegeven. Dit kan met de fq-parameter: https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?rows=1&q=fahrenheitstraat%201,%20's-hertogenbosch&fq=type:adres
Dank voor je uitgebreide antwoord @fsteggink! Ik had niet verwacht dat er een andere methodiek achter de services zou zitten, maar dat alleen de output (format) verschillend zou zijn. Dat kon ik ook niet in de documentatie vinden