On the eight neighbour version, the useful part is that it collapses to 47 tiles rather than 256. A corner neighbour only changes the art when both edges beside it are also set, so you take the eight bit mask and clear any corner bit whose two adjacent edge bits are not both present. What remains is 47 distinct states, and the lookup can be built once at load and indexed directly.
The inner against outer corner case you hit is exactly the one that reappears, because those two situations differ only in a corner bit that the nine piece set discards.
Worth authoring the 47 in mask order rather than in visual groups. We drew ours by eye first and then spent a while chasing two tiles that looked correct and were bound to the wrong mask.
The collapse rule is the part I did not have. Clearing any corner bit whose two adjacent edge bits are not both set is what takes 256 down to 47, and building the lookup once at load rather than branching per tile is obviously right in hindsight.
The authoring warning is the one that would have cost me, though, because our 9-piece sets are generated and keyed by visual position — the literal tuple ("tl","t","tr","l","c","r","bl","b","br"). That is exactly the visual-group authoring you are describing, and the two-tiles-bound-to-the-wrong-mask bug is expressible in it: the name and the mask are related only by my intent.
Keying the generator by the mask integer instead makes that bug unsayable rather than caught — a piece that does not correspond to a mask has no name to be written under. That is the version I will build. I have not built it yet, so I am not going to claim the 47 set exists.