Mstn CE introduces lots of powerful tools. One of them being the new Parametric Solids which have two powerful aspects. They "keep a record of how objects are built. When you change parameters in the element, the element is updated automatically. MicroStation re-executes the operations used to create the object using the new inputs to generate a new result." ie they maintain a procedural 'creation' history.
The other powerful thing they do is supports constraints based modeling. This allows things like edges to be offset parametrically. Kind of sound like 'clearances', right? More on this later :-)
Watching this vid about Clash Detection, you can't help but think that a lot of clashes can be avoided by having parametric dependencies between objects that are prevented from doing so because they do not 'live' in the same file or by design because of the need control design responsibility and change.
But a lot of really small changes should and need be automated. Examples include penetrations. Most would agree that automation is OK for this kind of thing. If not you will end of with tons of clashes that need to be cleared repeatedly. Easy if everything is in one file like the Speedikon example above. Less so when the structural member is in another file which the MEP modeler can't or isn't allowed to modify. This 'over the wall' type of working results in and relies on unhealthy amounts of clash detection (when what you want is clash avoidance of the minimum of clashes). Yes, I know things like Shipconstructor has fancy stuff like an SQL database to manage and propagate the changes across files; and Revit has its Copy Monitor tool. I suppose Openplant will allow you to check outs bits of both the structural and piping models and de-merge them back together. All have their pluses and minuses.
What if you could make those clash detection 'spheres' or markers parametric/rules-based?
Take the example above. The architect models a ceiling. The structural engineer models the columns. The columns penetrate the ceiling. Normal stuff. Every time the structural engineer changes the column diameter the ceiling clashes, generating a clash... highlighted by a marker of some sort.
Why not make the marker a Parametric Solid 'header' element and tack some GUID or schema info on to the marker that would allow it to re-build the penetration if there is a clash? The parametric marker would use the GUID or schema info as means to find the input element (column) in the Ref attachment for use in its mini Feature Tree. The user would select the spheres using the CD tool's criteria tools. The markers would give him precise feedback on which columns are affected. He would de-select the ones he did not want to update and then trigger the 'healing' update.
Navis (like Bentley's Promis-e) can zoom the user to the 2d representation of a 3d element - and vice versa- by matching GUID information. Not all verticals use GUID's and ElementID's are apparently volatile. So, additional 'clues' like user defined clashes become important correlating tool for linking elements across files. Not sure, CVE Element Handlers seem to be able to retain a stable link back to their originating 3d geometry. Maybe they could be used to link the markers to the clashing elements.
Clash Detection is only one side of the coin (or tip of the iceberg). No point providing fancy tools to detect if we don't get effective tools to resolve the clashes quickly. This would only give your employer another stick to be beat you with, which he didn't have before :-)
A clash is still a type of relationship (albeit a dysfunctional one). What if the marker could also store parameter information like the diameter of the column? if the diameter changed on the next 'clash detection' run, the marker would update the penetration through the ceiling. The 'clash detection' run would morph into a 'change detection' run... pulling changes from the external Ref attachment and not having them automatically pushed on you.