Please forgive my late re-entry into this discussion.
The main thing that distinguishes tunnels from other segments is the lack of GPS data--and the problem we are trying to solve is not how to detect tunnels or designate them on a map, but how to route through them when faced with that lack of GPS data. (In fact, if equipment were installed in certain tunnels that provided both accurate GPS information and data service, they wouldn't require any special handling at all.) A guideline of applying a negative elevation to a tunnel segment is harmless--as long as the routing engine doesn't start making assumptions based on it.
As I have mentioned ad nauseum, there are sections of the Central Artery in Boston where underground ramps crossing both above and below the main tunnels, all directly below both street-level and elevated roads. It's a perilous area to edit, and any one-size-fits-all rule about relative elevation is almost guaranteed to fail at some point. [I am not aware of any place where we have run out of negative elevations and need to assign a non-negative elevation to an underground segment, but it could happen. I am certain that we have had to use a -5 in more than one location.]
As for the more important problem of navigation, I'm still convinced that the only manageable way to navigate a network of branching tunnels (in which GPS and/or network connectivity are unavailable) is to treat the entire "dark" graph of segments as a black box with M inputs and N outputs, and each of the (MxN) combinations has its own total length and transit time. The segments are visible to the driver, editors and routing engine for the sake of calculating distance, displaying the map, generating turn instructions and (maybe) generating the "black box" data structure itself, but any attempt to treat each internal segment between points A and B independently, as is done above-ground, will be a combinatorial nightmare.