@octade I'm not exactly sure what you mean by "neighbourhood referencing". But the general data-structures aspects are:

1. In the grid.c system (which already exists in the published code, used by Loopy), a grid is represented by lists of faces, edges and vertices, and stores all the adjacencies. So you can directly look up the vertices belonging to a face, and the faces sharing a vertex. The neighbours of a tile T for Mines purposes are the tiles that share any vertex with T. So to enumerate all of them, you iterate over T's vertices; for each one, list the other tiles that have that vertex; and de-duplicate the resulting list.

2. In the Mines _solver_, we must store a lot of pairs (set of tiles, number of mines in that set). Initial pairs of this kind are derived from a clue square, so they consist of the neighbours of the tile containing the clue. Further pairs are created by intersection, so they're subsets of the initial ones. So all of these sets are localised to a small area of the grid. In current square-only Mines, they're represented as the coordinates of a particular 3×3 section of the grid plus a bitmap selecting a subset of the 9 squares in that section. But in new general-grid Mines, the contributor has simply arranged to store a sorted list of the tile indices, and the locality property just means the lists have bounded size and don't need to be reallocated constantly.