As @TLiebich explained, spatial structure elements are abstract hierarchical project breakdown structure elements and therefore any geometric representation attached to them is very sketchy. What would that even mean? The extent of a building is the sum of its parts. If there are no external walls and a roof, there is no building.
If a pylon is just a conceptual grouping of parts i.e. it is not one physical thing (could still be made up of parts) that is assembled on-site, then IfcBridgePart makes sense. If you are treating your pylon as one physical element that is assembled off-site and brought as one piece/product and installed on-site, please opt for IfcElementAssembly.PYLON. It is a matter of physical element vs organizational project structure. For this reason both a spatial structure and an element assembly can be typed as a pylon. These were the requirements of stakeholders in the IFC Bridge project.
Albeit IfcRelInterferesElements as mentioned by @aothms was expanded to ‘model’ interferences in spatial structure (was just elements before), it was not meant as a voiding type of concept. Unfortunately, there was never a broad consensus on how to use it and was more of a political consensus than a properly documented concept template. See here: https://github.com/bSI-InfraRoom/IFC-Specification/pull/40 → It is merely a possibility to have a reference to a footprint geometry if a road and a rail part interfere with each other. The hierarchical nature of Spatial De/Composition and Spatial Containment inherently does not allow one element to reside in many spatial containers i.e. spatial structure elements. Meaning, voiding makes little sense.
The exception to the above were curtain walls that were not modelled per storey and were IfcRelReferencedInSpatialStructure. I cannot say this is the clearest and I cannot remember seeing it in IFC4 but it was an exception. I would have seen a more clear approach in containing overreaching IfcCurtainWalls in IfcBuilding. Digressing, so shutting up now.