Where we go from here

I'm sorry, must have missed that somehow. Message me again and we can put you into the team working on all this.

Yes, this is something that has been mentioned from the start and we (actually I) are working on a threaded view. It's not easy because it's fundamentally at odds with the way that this forum software works, and has some very negative effects that occurred on DPReview. So, for instance, if a most was deleted, all replies to it, and the replies to those replies, and so on would get deleted too. Very often most of those posts would not have much relation to the post that was deleted - so people would find their thought-out and carefully crafted posts disappearing because someone had used a rude word further up the thread that they never saw. It also has severe performance issues. The whole of DPReview is based on a threaded model, which I suspect is why it got sol slow as Amazon reduced its server resources. I suspect that being threaded based with the activity it had, it needed lots of server resource to be acceptable in performance.
So we are trying to produce a threaded solution which doesn't have those problems, but it does make implementation quite hard.

That one is the relatively easy bit to solve - you don't ever delete a post, you just delete the content, and make it a null, invisible node - so that all the succeeding nodes can be linked to it. But then you have the problem of quotes in succeeding posts, what if they contained the text that caused the post to be deleted? So now all succeeding posts need to be searched and any quotes within purged. If you'd thought of this before you started, you'd make quotes references to the original post rather than copying the context across - that's a better solution, but it fundamentally changes the underlying structures. So, you go back to post purging, which is problematic in its own way. Moderation facilities make these features much more difficult. It's helped here by the fact that we hardly ever delete posts, rather we move them to the Dumpster. That will be easier with an embedded threaded structure, because whole subthread can be moved in one go. But it leaves the problem that posts which contribute positively to the original thread end up in the Dumpster. The model of threading that I'm using, which is based on post order rather than linked lists helps that, in that relative ordering can be retained even if a few posts are removed.
The efficiency problem can be fixed if the whole site is based on a suitable structure, called a B-tree. It isn't here or on DPReview, and it's a pretty fundamental change. The underlying Django and Postgres systems on which these forums are based allow B-tree searching, but because they aren't the underlying structure they are implemented using separate data indexes which can become very large indeed. I'm addressing this problem by only implementing threaded order within a thread, which slightly complicates the reordering problem above and depends on facilitators doing the job properly when they move a sub-thread. So, they can prune a branch, but decide to leave some posts unpruned, and those posts go at the right place in the original thread. Once they've been put in another thread, putting them back in the right place becomes more difficult.
This might be a bit technical for some, but it's just to show that it is being done and that it isn't simple.

Searches are a different problem. All the posts data here is kept on an SQL database. Searching really requires direct access to that database to be efficient - which there are facilities for. In that sense searching is somewhat a separate problem from the viewable structure. In terms of our development, it's also a separate problem.

They have to work, IMO that's all.
It would be preferred that search results displays posts in posting order (descending) - there are some forums on the wild, where search results are in random order, totally unusable.
Posts structure (flat or by thread) is not directly related to search - for search posts content (not structure) has to be indexed for full-text search.
I personally don't use forums search facilities, unless they are not indexed by google - this happens, but rarely.

Lets not go there on this thread please 😁

Personally, I'm completely with you on the on the approach - and it's the one we use, we hardly delete anything. It's not 'offensive' things that are the problem, it's the downright illegal, which we do need to delete. Still, the thread view solution I'm working on won't have the problem.