In my opinion, either a dialog or a max length parameter would be a much worse bother for the player than making a wrong tunnel. There's no way I would accept to be bothered every time I want to build a tunnel. I removed the max_height parameters from pak128's bridges, it will be the same for tunnels if they get a max_length parameter. Basically, clicking on the right place is the responsibility of the player, the good solution would be to extend the construction cancelling feature to tunnels.
I agree that such dialogs would be bothersome, but that could be circumvented by having settings to turn them off, similar to the message center. I suppose this wouldn't be too hard to add in the implementation, as it just wouldn't show the dialog and continue the code as if it was confirmed.
Turning them off would be a required feature anyway, as it was stated several times in the past, whenever some kind of confirmation dialog came up, that this would not be the Simutrans way. Eg:
Simutrans doesn't do confirmation dialogs. This is mostly a design principle, but that might have led to some technical aspects as well.
Hence if anyone were to start doing confirmation dialogs, it would not be sufficient to do them in this one case, but they would need to go through the whole game, see where they would make sense, and add them in pretty much everywhere. This would include terrain changes (you never know how much it costs in total, especially if you drag) bridges (similar concept to tunnels, really), ways when buildt with two clicks (no way of knowing where it would be buildt), any destructive measure (common in other games) etc. - it's not just one feature, it's a design decision, so if you revert the design decision, you have to redesign everything that followed the previous paradigm. This would be a massive change in how the game is played, and most expierienced players would probably be furious if you force training wheels on them. It's definitelly not as one little change if the game should stay consistent.
max_length and max_depht, on the other hand, might be useful for completely different reasons. They could stop players from circumventing any difficult mountain terrain by use of tunnels. My vision would be that each tunnel tile must be within [max_length] tiles of a portal, or it could not be buildt, unless it's 0 so no check is performed; and it can't be placed deeper than [max_depht] layers under ground, unless it's 0 so no check is performed. When a tunnel portal is about to be deleted, go through all tunnel tiles within the highest [max_length] available for that type of way and perform the same check, so all 'impossible' tiles are deleted - unless there is a train or something, in which case the deletion fails ("tunnel is not empty") - similar for any tunnel tiles, but the check could be simplified to ask whether all tunnel tiles previously connected to this tile are still allowed, and if not, prevent the deletion ("this would cut off part of the tunnel")
Since max_depht is supposed to indicate tunnels digged from above rather than drilled from the side, the max_depht parameter would only matter on construction but not prohibit later changes on the terrain above (also for practical reasons)
This way, you could have tunnels with no max_length but restrictive max_depht, such that you can build a subway system directly under the roads, as well as tunnels with no max_depht but restrictive max_length, which can go through a mountain, but only ever so deep (note: the tunnel can be twice max_length long, since it can be drilled/digged from either side)
Those parameters would not help with existing paksets though, but since they were brought up - I think they are a good idea. (players might remove those limits for single-player-games, which might as well be another simuconf option, but it wouldn't work in multiplayer)
