I concur with the opinions here. It always seemed odd that nested YAML was something that is harder to work with in Obi. Overall it helps with sorting and creating supersets of elements.
It would be even cooler if we could define a YAML “class” that is effectively a new property type that works like an organized property template.
Much of the meta data I hold onto would be flattened if the Obi team did this.
I may be wrong, but it seems to break the dataview. Nested fields are separated by a dot.
Sorry if it wasn’t clear, but I didn’t propose to rename the key.
book.started would only be for display in the Obsidian editor, not as a YAML key.
Basically, when Obsidian parses the frontmatter YAML, it could implement a simple function to flatten the nested structures before displaying them in the editor.
And If someone writes a property name with a dot ‘.’ in the key, it would be considered a nested field when written back to YAML.
Currently, if one writes a property key with a dot ‘.’, it will appear exactly as written in the YAML, and Dataview indeed won’t be able to read it properly.
The tricky part, I guess, occurs if someone writes the following in the editor:
book.format = Digital
created_at = 2023-09-01
book.status = Reading
because upon converting it back to YAML, it has to be written into something like:
book:
format: Digital
status: Reading
created_at: 2023-09-01
and thus, the ordering could change between book.status and created_at. But I think it’s quite rare for people to not want to display those in the same nesting consecutively (?)
Alternatively, I think having some kind of property “grouping” in the editor display would be nice. But this is more challenging because the current autocomplete assumes that property key will only be a single string.
I’ll also throw my hat into the ring for this. Prior to properties being released I managed note metadata with inline dataview fields, largely because this gave me more control over the aesthetics and organization of metadata in my notes.
I like the look and features of the new properties system, and started updating my PKM worflow to use properties instead of inline dataview fields, but I ran into an issue of poor aesthetics and usability / readability in the properties UI when the number of properties grows large (see Properties UI: add option for inserting visual elements to help visually group related properties). Thus the ability to nest properties seems really important for both aesthetics and functionality, especially when the number of properties in a note is large.
This has caused me to hold off on further integration of properties in my PKM until the nested property issue is handled, as I find it’s not feasible to use properties as it’s currently configured for notes with many properties.
Another plus one for this! I use YAML frontmatter to track habits on daily notes. So, I have a number of properties that look something like this:
habitCategory:
habit1: 0
habit2: 1
habit3: 1
...
A few automations also interact with that frontmatter. I could change those, but the bigger problem is that the properties currently look like this:
+1 yep, lot of nested attributes now requiring source view mode to perceive let alone edit. Would be nice to be able to toggle the properties header without going into source if a full solution is a long way off
Thanks for opening this request. This is the first time where an update in Obsidian actually significantly decreased its functionality for me, and it’s such a bummer to have a program you love become less useful over time, not more. I have read the posts on the reason for implementation of properties and it seems like it’s been well-debated and thought through, but hopefully nested properties can be incorporated in the future.
The implementation of properties has been less than smooth, IMHO. Chiefly:
Perfectly functional nested YAML text is now rendered as “unknown type” properties with long JSON strings as the value.
Numeric YAML keys (e.g. weight: 175) were converted by default to text-type properties (weight: “175”, requiring dataviewjs queries to now include parseInt() functions to force back to numeric type, or go back through your entire vault and change the property types one by one.
Discouraging manual entry of metadata by making it very cumbersome to avoid using the new properties GUI (e.g. working only in Source Mode). I don’t necessarily have a problem with GUI in principle, but this one is extremely slow to enter in a long list of properties, and additionally, you can’t easily copy and paste them to another document now (this must be done one-by-one), which you could easily do before.
A “use it how we tell you to” approach is not in line with the Obsidan user culture as I experience it. I do see how removing the necessity for strict YAML formatting could improve the functionality overall for many users, but hopefully this doesn’t have to override the needs of others using strict YAML in their vaults already.
If the new properties feature can incorporate nested properties in the future, I’ll welcome the whole thing with open arms 
Ah it seem I can go back to the previous look by setting “properties in document” to “source” within the editor settings. This helps!
Yes, that’s how I have it set. However, if you go out of edit/live-preview mode into read mode, any nested properties will be displayed as an unknown property type with a json string.
Properties broke YAML frontmatter for my use case. It needs to fully support YAML (including nested objects) or at least be possible to disable it entirely.
I hope the upcoming Databases feature that will use Properties will support multi-level YAML. See roadmap.
+1 from me on restoring this functionality. I am holding off on making any workflow changes until this bug gets resolved.
Thanks for flagging the roadmap! Looks like the dev team are still working on properties, so I am crossing my fingers and toes that multi-level YAML will somehow make it in.
I just wanted to add a +1 for this feature…
I make extensive use of lists-of-dicts in my YAML frontmatter.
Examples are things like on the file for a book, I’ve got
readAt:
- started: 2023-08-07
completed: 2023-09-10
format: digtal
ISBN:
notes: I re-read this because...
This structure is re-used for a lot of things, like a “significantDate” list on my notes about People as another example. This allows me to use DataView queries to show any significant dates for anyone I have a record for occurring in the next week, or list all the books I’ve read in read-order, including multiple re-reads.
I’m fully willing to admit that I may be Using It Wrong™ by abusing frontmatter in this way, and that it would be better to do things in the markdown body itself, but I have yet to find a way to mimic the usability and searchability and so am highly dependent on having these lists of objects in my frontmatter.
I have to say that so far I’m not a huge fan of Properties because of this. Now instead of “Reading view” being nice and clean and keeping the metadata hidden I have to manually fold up the properties for each file. (Reading view should really automatically hide the properties I’d say…) But once again I know I’m abusing the system in probably unusual ways. Just such very useful ways… 
Thanks for pointing that out. I was looking for a setting like that, but couldn’t find it.
+1 for a robust Properties editor
However, I am not all that familiar with this concept. What is the functionality multi-level YAML allows? Could you provide a use scenario?
YAML is just a markup language. Literally
YAML = yet another markup language
It doesn’t provide any functionality, it is just the way to organize your metadata.
consider
---
family:
mother:
name: Mary
age: 50
father:
name: John
age: 55
---
then we can use it somehow like frontMatter.family.mother.name
Can it be rewritten without multi-level YAML? Sure, it can
---
family_mother_name: Mary
family_mother_age: 50
family_father_name: John
family_father_age: 55
---
and be used like frontMatter.family_mother_name
But for me it looks less readable, tons of repetition
Nestedness is the key concept of YAML, not supporting it, in my opinion, is a drawback
And I am not even talking about other more advanced YAML techniques such as references…
+1 for nested support. Pretty important to my workflow. Grateful to the devs for continued work and development on obsidian.
+1 from me