I half-agree. Nested areas are the right taxonomy for a home and probably the most flexible from a user perspective - but don’t necessarily give useful geospatial information into HA for the future (which I think was the intention here?).
If you are going to have the concept of floors, then you also need to have ‘buildings’ and then worry about ‘inside’ and ‘outside’.
The ‘ownership’ of property in law is by ‘property’ so every jurisdiction in the world has that root point as a concept, each property has a number of ‘buildings’ and they have an ‘outside’ and an ‘inside’, and the ‘inside’ has ‘floors’ and each ‘floor’ has 'rooms '- if you are trying to capture geospatial categorisation in HA in a uniform way.
Yes you can do all of this with labels (of course - and FABULOUS labels are now here - I can create whatever hierarchy I choose with those - let the chaos begin - but it does feel like I’m overloading the purpose of labels), but the addition of ‘floors’ is (imho) a partial solution that will just cause people to overload ‘floors’ to the point that they don’t do what you wanted them to do in terms of capturing spacial information.
By way of example. I have a 2 ‘floor’ house with several rooms, I’ve also got an external garage and a driveway. There are internal and external lights (and other devices) in all those buildings.
So I have 2 buildings, 1 has 2 floors and 1 has 1 floor.
Solving with floors:
I can of course create 5 ‘floors’ (house-outside, house-downstairs, house-upstairs, garage-outside, garage-downstairs) but then there is no relationship between those naming schemes that can usefully be inferred in the future.
Solving with nested areas:
I could have nested areas ‘property.building.spacial.floor.room’ type scheme or ‘property.spacial.building.floor.room’ - so ‘property.garage.inside.downstairs.workshop’ or ‘property.house.inside.upstairs.bedroom’ for example. Or drop the inside/outside distinction and have those as floors: ‘property.house.outside.patio’.
Solving with labels:
I label everything in the house with ‘house’, everything in the garage with ‘garage’, everything on the inside with ‘inside’ etc etc - works nicely, assuming I can arbitrarily group in a scripted way against those labels.
My point being that ‘floors’ is just a single point of spacial information (if that is the objective here) and by introducing that without some form of regimented hierarchy (so something that code in the future can rely on as meaningful) such as ‘building->floor->room’ is just shifting the ‘overload’ problem from the names people have been giving things like automation or areas to another place. People will now just remove one level of the hierarchy and move the rest into floors - which will just overload again.
If you want to solve this properly, in my view, you either have to let a free for all hierarchy take place by allowing nested areas (and forget trying to regiment and capture spacial information in a structured way), OR you have to regiment a hierarchy that you can rely on in the future that has some basis in the way the world works.
Create a geospatial naming scheme that has a basis in hierarchies that are widely in use in the world today - property->building->floor->room. The top levels can easily default to property = name of HA instance, building = “Home” for the base case.
And as a side note, in the previous post someone quoted that the idea of ‘areas’ came about because ‘rooms’ implied a physical ‘wall’ (I’ve lost the quote but it was in the GitHub discussion and the previous post refers to it) - the conceptual problem I have with creating ‘floors’ in isolation is the exact same point - floors are just horizontal walls. If you are going to add a physical naming point that does imply a ‘physical boundary’ then great, but my suggestion is do it in a way that represents the spacial hierarchy people think about in their homes - not just pick an arbitrary point in the middle of the taxonomy.
)