The whole hierarchical / multiple membership aspect needs some form of discussion and implementation, whether it’s rooms , categories, groups or just tags. HE is in early days of any useful adoption of such groupings with non overlapping rooms and I appreciate why time is being taken to evolve this further. It’s not straight forward.
This I think will always be a complex and poorly defined concept, proven by no other software providing an ideal solution. I don’t think it’s worth thrashing about all the permutations.
I personally would like rooms to not support sub rooms ,as now and categories added like heating, lighting and implemented the same with no sub categories. Areas might have multiple rooms eg ground floor but are essentially a collection of rooms. Rooms should support multiple categories and categories should support multiple rooms. Groups if implemented are a collection of devices or categories.
So for useful functionality and sorting I think a device should be assignable to one room and to one category but should be able to be a member of several groups for control.
Alternatively, or as something useable given it’s tough to model , opt to just allow multiple tags per entity which are totally freeform and can be parents containing child tags which could be rooms , categories, devices etc. (in practice these actually are just more tags). Essentially just allow hierarchical tags in any format and we as a user utilise them as we wish. The fact that ‘actions’ applied to a tag might not be appropriate for all tag members is up to us to sort out and should just be skipped if non actionable. Don’t attempt a tag status. If there’s a way to protect against users creating tag loops, ie sub tags that are also parent tags then great but if we break things this way then it’s our own negligence.