Clash detection seems to be a really poorly understood process.
Management seem to think that this is a 'static' endgame process where you start out with a high number of clashes, have a meeting to 'bang heads together', get the number reduced, hold another 'head-banging' session ...and eventually you get to Six Sigma Nirvana (or run out of heads :-)).
It's actually more of a dynamic thing. The clash count often goes up as as well as down as the project develops.
Change is the big generator of clashes. Your structural or MEP engineer shares his model(s) and... boom! changes galore that produces a new wave of clashes. The clearances you thought you had are gone or your pipe is now running into a column or beam that wan't there before or moved slightly.
Seems pretty obvious... Then why not provide the Clash Detection tool an option to use DH/DS/ISM to identify the New, Modified, Deleted elements in the incoming models? I know DH is not very popular because it increases file sizes... so maybe a geometry comparison tool could be added that compares the current version to the previously shared version to produce a list of new, modified and delected elements (at the sub element element level if required).
ISM already tracks the new, changed, deleted elements. Who knows, maybe it is just a simple case of publishing ISM's and not i.dgn's (which is what we do currently) for clash detection.
Bentley has been ahead of the game by integrating CD tools into the authoring app. Thereby facilitating pro-active Clash Avoidance in addition to retro-active Clash Detection (which tends to be more expensive). But, a significant amount of clashes can not be 'avoided' and have to dealt with when the model(s) are shared.
It is also important to understand that resolving clashes involves making changes... which inevitably result in more temporary clashes that need to resolved in turn. This means that it is important to be able to identify and start with the 'key' clash-generating or 'source' element, and sequence/prioritise the de-clashing exercise productively.
For example, it is no point resolving clashes between MEP elements at the bottom of a ceiling void if there is a clash at the top of the void due to a change in the incoming structural model, which will push all of the MEP elements down anyway. You need to be able to identify the 'root' clash and ripple out from there. If not you will be chasing your tail in a wasteful exercise in Negative Iteration.
So, it would be good to provide 'new, modfied and deleted' criteria to the Clash Detection tool.