I've been thinking about this sentence for several days now. You're right, a forum shouldn't be flat. And a forum about code perhaps needs a dynamic, fluid topology.
An HN-style forum like this one can be traversed in a couple of ways. You could start with item?id=1 and continually increment. You can also navigate the stories in reverse order from /newest and thence to clusters of comments belonging to them. Old-style forums like http://forums.linuxmint.com permit a third dimension/ordering for traversal: time of last post.
A dimension has the property that you can start at one well-defined end and travel in one direction and be sure you saw everything. This is a useful property, not because we expect users to do this very often (though some will) but because it hooks into our spatial metaphors for information in an intuitive way. We tend to have a sense of the neighborhood of a post, to place a mental bookmark on how far we've read. Above all, they help in browsing in search of a post.
Can we come up with new dimensions for a forum? Sometimes I find myself wishing we could see posts here ordered by the place in the arc codebase they are referring to, suggesting changes to, etc. Anarki we can actually make changes to, so perhaps there's a possible 2-D space of revisions + file + line number. I don't want to go too far off the deep end with the topological metaphors, but there's likely a useful 2D ordering for a forum.
Some dimensions can be more useful than others. File+line number isn't ideal because the ordering of functions is often arbitrary. Just space+time isn't ideal either because the same change may show up in many ways, and because changes close together in time may be utterly unrelated.
I'm not sure what the ideal dimensions are for our forum, but this idea bears experimentation. Imagine a forum where you can define new dimensions as 2 functions: one to convert a new post to a coordinate, and another to render a neighborhood of coordinates. Now anybody could download the posts and sources, and experiment with different ways of browsing them. You could order the functions alphabetically or by types or other categories. Or you could seek out an equivalent of the dewey system.
"A dimension has the property that you can start at one well-defined end and travel in one direction and be sure you saw everything. This is a useful property, not because we expect users to do this very often (though some will) but because it hooks into our spatial metaphors for information in an intuitive way."
While I see some value in that kind of pursuit, I'd like to even the field of discussion a bit. Humans may live in a low-dimensional world, but they move around, manage a changing environment, and maintain different levels of human-to-human association even within a single population. I think it's plausible that humans evolved to reason about both spaces and networks.
Maybe an interesting scientific-ish approach would be to look at what parts of the brain are involved in forum use. If there isn't enough activity on the right side of the brain, we could work on spatial metaphors. Once there isn't enough activity on the left side, we can go back to language-like metaphors. :-p
"Imagine a forum where you can define new dimensions as 2 functions: one to convert a new post to a coordinate, and another to render a neighborhood of coordinates."
I don't think it needs to be formalized that well yet. If the forum software is itself an open source project like Anarki, that should be stable enough for a small, dedicated community to experiment.
I bet once people can browse source code repositories with forum topic annotations on the side, it'll be a while before other features begin to appear necessary. If nothing else, the UI design and module system integration of these annotations would be finicky enough that the developers would have to chew on it for a while before they take on yet another revolutionary change. :-p
In a more secure and seamless model, well, I'd go with David Barbour's vision and say all state (e.g. the state of a project under development or the content of a discussion) would be hooked together using RDP, and individual state models would have continuous, idempotent interfaces that were designed for view composition and concurrent modification in the first place. The issue of designing forums for programming would naturally decompose into designing composition-friendly repository models, composition-friendly discussion models, the discussion of composition-friendly UI state models, and maybe some remaining issues with composing these models over RDP in practice.