I'll contact you offline to see how we can improve the exchange.
But let me also respond here on a few points just for the benefit of anyone else reading this post. A book could be written on this topic, so this post will be both much too long and much too short.
Using IFC as a stepping-stone between ArchiCAD and Revit presents great challenges because of the great differences between their underlying technologies and the logic they employ to convert human intent into deliverables. As BIM authoring tools, they are fundamentally different from Solibri, Tekla, or Navisworks.
In order to make a sound business judgment about how (or whether) to use IFC in a collaborative workflow, you need to start with an honest understanding of what can efficiently translate into IFC from one tool and come out in the other tool. This is a bi-directional question and it is even more challenging for content that needs to make a round trip, rather than content on either end that only needs to cross one time. For round-trip content, simply editing some of that content second application, adds yet more friction.
So let's start with what IFC exchange will not achieve between ArchiCAD and Revit. If that turns out to be unacceptable, then we can use other techniques and workflows to supplement IFC, or supplant it.
A good basic contract-deliverable production-BIM in Revit or ArchiCAD cannot be authored in the other application. Indeed, even staying on the same platform with Revit Architecture and Revit MEP, has serious workflow challenges that surprise people who have not run such a project in Revit.
You mention in your second point that the MEP engineers cannot host their fixtures on walls authored by the architects. But surprisingly, in Revit this is not a practical workflow anyway unless both teams work in the same model. And if the teams are on different Local Area Networks, working in the same model is more difficult in Revit than programs you may be familiar with such as ArchiCAD, AutoCAD, MS Office, etc.. So in practice, different disciplines typically work in their own models that started with templates optimized for their own needs. I only mention this to make the point that sometimes ArchiCAD users get unfair criticism for their contributions being incorrect or incompatible with other platforms. The truth is that Revit to Revit collaboration is a pain and so if you are getting compared to a Utopia that never actually occurs in Revit, it could be pretty frustrating. In practice, many experienced Revit MEP users have moved towards face based families or even un-hosted families for mounting fixtures "on" elements authored by architects.
So what is IFC good for? That is a moving target as Autodesk and Graphisoft make strides in improving their IFC translation. But so far, my experience with IFC workflows between Revit and ArchiCAD has revealed some criteria that relate to the nature of the content that translates across the chasm. Here is how I divide it up:
1. Native quality editable content. E.g. walls that are editable the way walls in the host application are supposed to be edited. This would include the ability to move, delete and add doors, stretch the wall, connect (join) other walls to it, schedule the imported wall properly along other walls authored in the host application. Ideally, the imported wall would also generate the graphical representation intended by its author. This means that ArchiCAD composite walls would arrive in Revit with the composite layers showing with correct thicknesses and fills in plan and section. We should not forget surface appearance in 3D and elevation.
2. 3D content that is geometrically accurate but has lost its essential quality as natively editable elements. In ArchiCAD, this would be like getting a wall saved as an object. Sure, this object could be called a "wall.gsm" and it could even have a generous serving of metadata attached to it. But no ArchiCAD user would consider it a real ArchiCAD wall, even if it were editable by "morphing" it. Likewise, a wall imported into Revit that gets translated into an "in-place massing" or even an "in-place" wall family, is not a true Revit wall in the way that a Revit user would accept as "best practices".
3. Simple elements such as solid straight walls..
4. Distorted, Missing/lost content.
I mention walls only as an example, but I'm talking about all the other elements, objects, and families in a BIM.
With all this in mind, I have found IFC most useful for 3D coordination. Using the BREP translation, you can get geometry and designation of what that geometry represents, to convey between disciplines so that you can see your model in the context of the other models. This is similar to bringing the models together in Navisworks, but with the advantage of staying in your authoring tool in order to intuitively edit the context of what you see. When 2D graphical representation is important, (which is most of the time) I supplement with DWG backgrounds.
Another tip: ArchiCAD imports IFC content pretty well but it is typical for Revit users to experience extremely long times opening IFC files of any complexity. Aside from the fact that Revit leverages multiple cores rather poorly for the important stuff, it has a special challenge with imported BIM elements; The Revit engine is designed to make the whole BIM parametric, far beyond what ArchiCAD is attempting to do. (BTW, ArchiCAD objects have always been far more parametric than Revit families.) I describe Revit as a "procedural database" while ArchiCAD is "relational database." What this means is that a Revit BIM is very dependent on not just the presence and position of authored elements, but also the order in which elements are authored. Indeed, the order of the authoring process affects the constraints that control the behavior of the model and even the resulting design.
ArchiCAD has few constraints and none that are not deliberately applied by the authors or applied automatically in a way that is obvious and expected. In ArchiCAD, an example of the latter would be that when we place a door in a wall, the door moves with the wall and even adapts its jamb conditions to fit the wall.
With larger IFC imports into Revit, the quantity and variety of elements that suddenly appear in the database without ordering information or constraints, creates a kind of "chaos" that needs to be sorted and categorized in a "procedural database" like Revit. That is why Revit takes even longer to import IFC data than it takes to export it. So, for speed and reliability, it is best to see IFC as a way to convey a part of your design that is relevant for particular decisions or design issues. If the whole building must be converted, you might have better luck saving it out in multiple pieces and reassembling them in Revit in a specific order.
More experimentation needs to be done with this and some can usually be combined, but here is the order I think Revit copes with best, in terms of elements being authored or imported into its database:
1. Levels (ArchiCAD Stories)
4. Load bearing walls
5. Non-loadbearing walls
6. Structural slabs
7. Non-structural floors
9. Lighting, Diffusers, floor mounted fixtures, casework, and furniture.
10. Everything else
Site should probably remain in a separate dedicated Revit model.
Also, avoid any content far from the Origin (0,0,0) point. A ten-mile radius from the origin is the maximum and I would stay well short of that if possible.
Lastly, the new add-on for Revit 2015 is improved over the one we had for Revit 2014. Likewise, ArchiCAD 18 is better than ArchiCAD 17 for IFC in and out.
Sorry for the long post.
RATCLIFF CONSULTING LLC
Charrette Venture Group
ArchiCAD 4.55 - 25
Autodesk Certified Professional in Revit
macOS + Windows