Ok I read the whole thread , and like I thought it was mainly the same idea as the current pathfinding with some tweaks.
For what I can read of your post you didn't get almost every part of my method.
No there is no problem with fortress without vertical access.
No there is no need of any internal pathfinding , a cube is convex , which mean that for any two points of the cube the straight line conecting this two point is also include in the cube. Just in case a cube can be a 1x1x1 tile, which means this method is in the WORST case localy as fast(slow?) as the current method.
I think you just don't understand the funnel algorithm, it's an algorithm which take a bunch of touching convex polygons (with our start point in the first one and the end point in the last one), and returns you a bunch of straight lines conecting the 2 points, these straight lines ARE the path.
The function that take care of the changing of the map only do local changes not global, so it is very cheap in calculation.
I think the fluid system is as simple as "it's water now" (with an index of 1 to 7), I think the fluid system just need to know what is the "fluid index" of every tiles to work, but I may be wrong on this one.
Ho and the navigation mesh is known to be the (actual) best pathfinding method.
Edit: http://www.ai-blog.net/archives/000152.html here is a nice site explaining and showing some nice example of nav mesh.
And yet, I think the problem is you're still not understanding what we are talking about...
Whether you call it a nav mesh or not, this is still functionally the same thing we have already been talking about, except for the fact that we are dealing with non-floating-point cubic tiles. You're coming into the thread, saying we should drop everything, and work on "your system", and then describe "your system" as being almost exactly what we were talking about (except that your is based upon floating-point distances), anyway, and then try telling us how much better your system is.
Also, no, it's not as simple as "it's water now". The entire node doesn't instantly fill with water. Only individual tiles fill with water, certain levels of water at a time, and do so sequentially - that means that at one point, there will be water in some of the tiles in one node, and not in other tiles in the node, and you are going to have to start splitting that node up and testing to see whether it fits in with other nearby nodes. There is an interface point (3/7 water) where swimming creatures and walking creatures can both occupy a tile. That means those tiles are probably going to be in their own individual nodes, and checking to be put in with other nearby nodes rather frequently, as water sloshes around randomly. In a situation with 3/7 and 4/7 water in a basin, the 4/7 water is going to be cutting off land access every time that 4/7 water depth shifts around, and that means the nodes are going to be cut up and merged very rapidly with one another. That's a potentially costly set of calculations to make, and something that can be optimized.
EDIT:
Since I probably need to go into further detail as to why "Funnel" isn't helpful - first off, the mesh system and polygons and linear pathways you are talking about are for floating-point-distance pathing. This is a grid-based game. The funnel pathfinding where you calculate how many meshes you can path down in a straight line is unneccessary calculation, since as long as you can assume connectivity without explicit pathfinding, there is no reason to have to worry about pathing around corners, anyway. There is no need to worry about making the "smooth line" or avoiding "zig-zagging" in the way that pathfinding is taking place already, so spending extra calculations to look ahead several nodes to make a straight line between the nodes is pointless.
Further, there is a problem you are ignoring when talking about all this - the pathfinding you are linking to assumes large open areas with clusters of obstacles and relatively few moving units. DF is a game where units cannot move through one another easily - collisions require both units to stop (or in pile-ups, everyone to stop), a unit to try to pathfind a sidestep, or failing that, everyone but one unit has to stop everything to let one unit advance one space.
Try having dwarves pick up a pile of random objects like stones left over from tunneling when you only have a one-tile-wide hallway for them to access it, and you'll immediately see the problems with the traffic pileups.
Consider a major pathway where the overall shape of the path units must take is a "U", starting or ending in the northwest and northeast with dwarves needing to go back and forth repeatedly, but needing to travel along a major hallway that connects portions of the fortress from east-to-west. Every dwarf travelling to and from those points would automatically hug the northern wall of the major hallway - colliding with every single other dwarf who is coming from the direction of their destination.
This was why I was advocating a "Highway" system - it may be slightly less dwarf-walking-distance efficient, but it manages to be much more efficient overall for the problem at hand, because if you assume that dwarves prefer walking along the right-hand path of a hallway, only deviating from that path to "change lanes" by stepping to the left in the highway to pass a slower moving walker, you can assume that in any hallway wider than one tile, you can at least prevent most head-on-collisions until traffic density is such that dwarves are going to be repeatedly attempting "passing" maneuvers.
This still assumes pathfinding automatically at everything but local "inside the node" start and end points, based purely upon the node's connectivity, but it manages to solve other problems the game needs to solve with pathfinding, as well.