I think I do...Something to remember about street shapes is that they dynamically segment themselves technical when exposed to curves. As a result, it is typically recommended to stick to UV based operations (insertAlongUV changed much of what was possible in the Complete_Street.cga rule for this reason). However, images help tell this story. I applied the TOD.cga rule in the Land_Use folder of the Complete Street repo linked above to three different streets, each manipulated differently. Notice how, the curved non-straight street broke multiple times based on the shapes articulations. Instead of one building, I have dozens. You can see how the complete street rule by comparison is depending on inserted shapes/models, simple extrusions, and textures.
Based on this you have a few options:
1. Keep the street shapes as straight as possible. Remove all curves from the geometry.
2. Use insertAlongUV with predesigned shapes/3D models. It is possible the envelop operation is not what we want here.
3. Something else. There are likely other ways to set up the shape. It might work now, but previously the comp operation (= vs. : - see the operator), did not work on street shapes to consolidate this segmentation behavior into one shape. It does create headaches. For example, if you can insert a thin base using the insertAlongUV operations, then component split the top of that shape with a = operator...it might keep it in one shape. However, in my experience, the envelope operation is very sensitive to starting geometry (I still don't have raised crosswalks for this reason.) .
Street rules are like programming on shifting sand.
David Wasserman, AICP