I am one who would fall into the “cloudy” category regarding relationships. Could you please explain why you used the {reverse_related_entries} tag instead of the {related_entries} tag?
Sure thing, jshcutt.
It all boils down to how the information is presented and displayed. The decision was basically made for me by the design. Related entries show one entry per custom field. So to get the presentation that I have here with related entries, I would need one custom field per every possible feature, and to publish a new feature, I’d have to publish the new entry in “Features Entries” and go to the parent “Features Category” entry, and swim through a list of relationship custom fields for the next empty one, and select my newly published feature entry. On the template side of things, I’d have to have a {related_entries id="foo"} tag for every custom field.
Reverse relationships allow me to make my “Categories” the actual children, and the individual features the parent. This lets me have only one relationship field, and only have to publish or modify one entry to add and make changes.
If that break down doesn’t help you (it’s late afternoon and very hot, so my explanation is probably not super) try thinking of it this way: A parent can only show one child per custom field, but a child can without any custom fields at all show all of its parents.