Since this is information that is useful only during layout, perhaps this change was made to make the Area Tree more lean (i.e. use less memory)?
IIRC it was made to allow areas GC'd early. In the maintenance branch, if something keeps a reference to an area, like tables did, the tree for the whole page is kept until the page sequence ends and the whole FO subtree can be reclaimed. However, the parent pointer isn't always set properly, for example line areas may not set it (fortunately, because basic-link keeps a reference to the line).
In both cases, the maintenance branch seems more correct to my naive eye.Uh, duhhhhh.... :-)
Is there any enthusiasm for a lowest-common-denominator approach to the area tree?
No. I'd rather have the bugs in HEAD fixed. Then refactor the Area heirarchy (factoring out a bordered area, for example), and get a more efficient representation for words.
The bad news is there are areas not corresponding to FOs.I am contemplating adding a "shadow" concept to the FO Tree that would allow a layout system to store data in an object that has a one-to-one relationship with a node in the FO Tree.