Here's another patch ... I think it's nearly ready.
I added "nearest neighbor" to the luceneutil London, UK geo benchmark, and getting top 10 nearest hits from the center of each of the 225 boxes that benchmark tests is extremely fast ... less than 0.5 msec for each call ... KD trees are very good for this
This adds LatLonPoint.nearest, and it now takes an int topN (vs. single nearest point in previous patches).
I think it solves the adversary issues of the previous patches, at least the ones that are solvable. Some are not! Imagine the index only contains many points indexed from a circle, and then you ask for nearest from its center ... no matter your algorithm, that will amount to a linear scan.
There's one wrinkle though: the search works directly with BKDReader, because it's a best first search across all segments, picking which cell (across all segments) is the most "promising" to descend into next. This means it requires that you use Lucene60PointsFormat (the default codec), and it gets the underlying BKDReader from that. I think making this work only through the codec APIs is ... tricky.
There are further optimizations we could do like using haversinSortKey, or maybe fixing the approxBestDistance to be a true best distance (I need heavy geo math help for that!), and using Lucene's priority queue not the JDK's, but these all can come later.