Re: Issue 1063 in lilypond: Reverting nested property fails to restore default value if preceded by override in same grob

[lilypond]

Comment #9 on issue 1063 by address@hidden: Reverting nested property fails  
to restore default value if preceded by override in same grob
http://code.google.com/p/lilypond/issues/detail?id=1063

Figure me annoyed.  When a nested property is being set, all the subpaths  
leading to it are copied from the context carrying the top property of the  
nesting, and an augmented subpath is prepended.  Any property lookup for  
any subpath of the top property will now happen through that copy.

Regardless of whether subproperties in parenting contexts get modified.  At  
the time that the whole tribe is copied, the relation to the originals gets  
lost.  With the current data structures, subproperties can't be overridden  
and reverted as if they were independent from other properties of their  
tribe (in the same hierarchy).

This is nothing one can fix by doctoring revert.  The whole concept is  
broken if I understand this correctly.

Can somebody give me an overview about what nested properties we currently  
have, and how they are accessed?  Are any parent properties accessed with  
the expectation that a useful alist pops out?  Or could we use different  
data structures for the parent properties in a hierarchy?