But it has a crippling impossibility, which is that sand and water are bound to meet up sometime, and 1/3 and 1/7 are completely incompatible.
The current system by which water (and magma?) flows interact with map geometry allows no fluid to flow through a wall tile but the full amount (up to 7/7) to flow through upward ramps/stairs. Why mess with what already works? Say that up to 7/7 water can coexist with 0/3, 1/3, or 2/3 of sand, but no water can coexist with 3/3 of sand. If a sand shift opened up a new tile that water could then access, it would flow in automatically (the water is already checking constatly to see where it can flow to); if a sand shift rendered a previously fluid-passable tile fluid-impassable (filling a water/sand tile up to 3/3 sand), the water could be displaced horizontally or, if that weren't possible, vertically.
Or, that water could just get atom-smashed, which is probably what would happen in the case of a cave-in with a natural wall currently(?). I don't feel like it would be a huge problem, except for someone wanting to pressurize an underground lake by dumping sand into it, as described earlier in the thread... I guess it would sort of simulate the water being "soaked up" by the sand, as was mentioned above.
I guess what I'm saying is, all of the thirds-of-a-tile-of-sand logic would be totally obfuscated, both from the user *and* from the fluid logic driving the water. As far as the user loo(k)ing at the tile would see and as far as the water flow would care, it would only be a "sand floor", a "pile of sand", a "sand upwards ramp", or a "sand wall" (rather than 0/3, 1/3, 2/3, and 3/3 sand, respectively), and the water would interact with those tiles in precisely the way that it already does.
So, the "sand shift" check would take place separate from the fluid flows, it would only need to be called when one of a (short) list of events that affect sand level (mining, collecting bags of sand, cave-ins) occurs, and then it would propagate outward, causing the next frame to call that check for the eight adjacent tiles, and any tiles in which a shift occurred would call a check for their eight neighbors in the next frame, and so forth until no more shifts occurred... *Vertical* sand shifts would take a little more doing, though, since a wall directly above a ramp would have to shift to form a ramp directly above a wall, so the cave-in code would have to change for sand walls... Point is, it wouldn't make that much computational work unless you caused a shift at the very bottom of a deep sand pile, and that is, I guess, reasonable enough? It almost can't be even as much work for the processor as punching a hole in the bottom of a lake is now, and that's something that people still do often enough.
EDIT: oh, and if sand were tracked by thirds, it might make sense to make "collect sand" reduce the level by one and produce a bag with, say, five or ten units of sand in it? It seems like a cubic tile full of sand would suffice to make fifteen or thirty glass crafts...