I really like the CityJSONFeatures in their intrinsinc definition. Still, I dont think they are really "features" in terms of the standard.

I list here some questions and my comments:

• As I understand it, the will of the standard is to provide resolved and easy to digest GeoJSON elements. However, the geometries are kind of hidden in the CityObjects object. From the standard, the geometries need to be an attribute of the Feature.
• As you said, CityJSONFeature need to have only one geometry for each instance. In CityJSON, multiple geometries are allowed in the "geometry" array. In the case where several LoD are available, how to choose between them? The unique way I see is to provide an additionnal parameter in the GET request. BUT it goes against the standard. Should it be part of some best practice (highest LoD, lowest LoD, ...).
• Common denominator of the two previous points: how to easily reach the children geometries? And moreover, here, we multiply the "geometry" attribute.
• Besides the fact that I like the idea that 2nd-level city objects are only relevant because of their belonging to a group (Component/Integral Object - Winston et al., A taxonomy of part-whole relations, 1987), couldn't it be damageable that their are not queriable independently? I mean, in a cadastral application, property unit or storeys have a reason for being. However, some BuildingPart are not.

I leave it here, for discussions.