Types are generated for mirrored objects or doors with different opening depths

I don't think there's ever going to be a fix for this, but for fellow bug searchers who stumble across this, I thought I'd document it.

Basically, let's assume you have an asymmetrical table in Revit from a furniture manufacturer - you have one type, and many instances of it. Now, if you mirror a single instance in Revit land, you still have one type.

This behaviour within Revit is incorrect. Mirroring creates a totally different product which has a different model number and procurement line item and installation method and so on. However, Revit treats both mirrored and regular instances as one type.

In IFC land, Revit detects this difference at export time, and will generate 2 IFC types from the single Revit type. This leads to a 1:Many mapping of Revit types to IFC types. This kinda screws up a lot of systems, but at least you get a correct IFC type. However, all the type information is duplicated, so you end up with non-unique type Names, and a scheduling nightmare if you ever work in IFC land.

The problem is more nuanced, with things like doors being flipped, also generating multiple types (but this time, Revit is clever enough to denote the swing direction in IFC - that is, if the family creator even followed the conventions for swing directions ... we cannot trust it though). So if you flip a door twice along X and Y axes, you can get 4 IFC door types from a single Revit type.

Then, when a door is placed in walls of different thicknesses or offset inside a wall, again, multiple types are generated, each with exactly the same geometry, just with a different local origin of the representation item (i.e. insertion point). A quick test on an architectural model shows there is about 60% of redundant data in the IFC file that we need to clean up due to this bug. I've dealing with a project right now where I've got 7 IFC door types from a single IFC door. Not very nice.

I understand this is a nasty a difficult issue with complexities on both sides of the fence - in Revit land Revit doesn't do enough of a job differentiating when mirroring should impact things and when the lazy modeler is really intending to do a 180 deg rotation instead. In IFC land, mirroring is a nasty issue which even though technically possible, is kinda something confusing and nobody really wants to play with it.

So I don't expect this to be solved, but thought I'd flag it on the tracker anyway.

The issue names no files, tests, or entry points. Start by reproducing the Revit export with mirrored objects, flipped doors, and differing wall depths; a resolution would need an agreed way to avoid redundant IFC types while preserving valid distinctions, but the issue provides no acceptance criteria.

Written by the indexing model from the issue text.