Retrieve data from nested family
What? Did I hear my name? 😜
In any case, I've [briefly] reviewed this thread and I think that if a very specific goal is established then it can be reached, but not in as simple or elegant of a manner as you desire.
Is the end goal to create a schedule in which each window family (which is identified by some parameter) will be listed along with the total glazing areas of all corresponding subfamilies? If so...
In the host family, you can employ reporting parameters or link-in the nested parameters and recreate the area calculation formulas, there (in a Shared Parameter). This will be easy to schedule, but every host family will have to be modified to include this calculation, which can be a pain if a host family includes a strong variety of glazing options (e.g. number/shape of areas).
-OR-
You could make the subfamilies Shared, and then 'push' the host Family's identification parameters (and perhaps all other scheduled parameters) to the nested families, and then make a window schedule that includes only the subfamilies and groups them together according to the identifying parameter.
There's a ton of nuance, here, so again, only a very specific ends warrants a very specific means. I hope this helps and that I'm not just repeating what's already been said!
──────────────────────────────────────────────────────────────────────
⁞|⁞ Please use
.Accept as Solution and 
Give Kudos as appropriate to further enhance these forums. Thank you!
Below is an example (2017) of using a shared nested family for the panels and subsequently, reporting the sum area for each window assembly via grouping in a project schedule.
Why would you want to change the sizes of the windows in the Parent? That defeats the mission you described; which was to “pull” data from predefined components. If you want to redefine the components in the Parent, you are effectively “pushing” data back. This would make “pulling” data from those components redundant, unnecessary – and overly complicated.
The Parent in my family is merely a “mulled” window family containing a combination of windows of a particular type size and shape and – vent and glazing area. The Parent is reporting a vent and glazing area as a cumulative total of all the different windows in the mulled assembly. Mission accomplished.
Now, if you want to resize one of those components, you would need to do this resizing in the component itself***. For instance, if the bottom window needs to be 500 tall and the top window 1000 tall, you would need to change those dimensions within the nested window family itself, and then reload it. Why? Because the parent is only “reporting” on the component; not defining it. Try it. Works like a charm.
Lastly, and probably what led to your “issue” and confusion; is that the family I provided back to you, only uses those parameters I pointed out: the ones categorized under “Data” and “Other”. None of your original parameters (which I did not delete) are used to drive any nested window parameters. So, consequently, they effect no change to them.
***The attached family differs from the last, in that both nested family’s parameter values for height and width are modifiable within the Parent – by changing their sizing parameter values under their Properties in the Parent. Changes made here will “report back” to the Parent, and will update all the vent and glazing area calculations. But note: these parameters CANNOT be associated/linked to parameters in the Parent – because then we’d have a dog chasing its tail. 
Hope this helps. Good luck to you.
@lukekvasnicka I'm not, Autodesk is emailing me telling me that there is a solution, I've not been near this thread until this morning. I think something somewhere is broken. It also seems to be adding 'likes' as well.
Sorry, but it's nothing to do with me.
So, basically what you are telling me is that this isn't worth the paper it was printed on?
AARGH! I'm sooooo disappointed. I had plans for this windfall. They're all dashed now.
boohoo.
