I did speak to them directly this morning. They said this behaviour is intended and that there are dead end branches off the main dead end path and that this fix was to prevent dead ends from being as crazy long as they used to be able to be (30+ tiles for example) but dead ends of 10ish tiles were still possible.
That’s all the info I have.
Can we please just get the user-generated graphic inserted in the game, it would literally solve 95% of problems, and will trigger the other 5% to look up more information so they understand.
Instead of worrying about what the code is or needing changing the code, which is more likely to just break things, just telling the players how to go about doing the underspire would mean NOBODY would ever encounter a dead end longer than 6 because it would literally always be a waste to go farther than that.
No, the fix was to prevent dead ends to be longer than 6 rooms long. They even attempted to do that and almost succeeded.
To illustrate it be bit better for the map posted above, this is the main path, marked in green:
This is the same map, extended with dead ends marked in red:
The white numbers are the dead end length counters. If you mark several dozen maps the same way, NONE will have any of those counters go above 6. This isn’t just a coincidence, whoever designed Underspire intended this to be “fair”, there’s a fixed limit on how far you can wander off into the wrong direction. Allowing extra paths that can be arbitrarily longer breaks the whole design. You might as well drop the fixed limit entirely, because players can’t tell whether they are on a “normal” or “arbitrarily longer” path.
Which brings us to the bug. In some very rare cases the constraint check fails. It seems to be caused by the dead end branch being located on an outside border and entirely locked in by other rooms, except the very last one (with counter 6). The algorithm will then attach extra rooms to the very end, without first verifying that it doesn’t exceed the fixed limit.
This SHOULD be easy to fix, once you get “them” to admit that the initial fix may not have covered all the situations it was supposed to cover.
Upper right - makes sense. We expected this.
Lower middle to left - this doesn’t make sense at all. That’s not a branch and a main path, that’s just straight on. Where is the branching off? You can’t just arbitrarily take a path that’s just a straight line of room and claim those are “branches”. That is not how a branch works.
Sorry but whoever told you that is telling you something that just doesn’t make any sense to any ordinary person who would look at this.
I know what they’re saying but it’s a stretch to call that branching off is what I meant to say. 
The fix should be easy. Do not allow branches from rooms, that are 6 tiles removed from the main path. If we take the pattern described by 4,21 up there as correct (and there is no reason to doubt it), those rooms should be the natural limit to any extension by design.
Not happy with the outcome but thanks so much for letting us know.
Looks like a bug for me. Any branch on pictures posted (including yours) goes 6 tiles long from the main path. Except the last one. Not “6 tiles long from the any arbitrary intersection”, as this one looks like. So it’s the edge case - but it is the bug, and must be fixed.
Thanks Kafka, this was very helpful!
