I'll let Tom speak to RMtrix, but let me try to address shared events vs. family events. The basic data model used by an early genealogy program called PAF involved individuals and families. This same basic "individuals and families" data model is used in GEDCOM, which is the standard file format for exchanging genealogical data between genealogical software. The use of the "individuals and families" data model by PAF and especially by GEDCOM has had the effect of promulgating the same data model to much other genealogy software. Not every genealogy software uses this data model, but even those that do not use it for their own internal operations have to deal with the model if they import or export GEDCOM files as a way of exchanging data with other genealogy software.
So what does this "individuals and families" data model mean? Suppose you export a GEDCOM from RM and as a part of that export you export John Doe, his wife Jane Smith, and their children Samuel and Sarah Doe. Suppose that you are exporting a large database and that John Doe is the 79-th person exported, Jane Smith is the 80-th person exported, Samuel Doe is the 81-st person exported, and Sarah Doe is the 82-nd person exported. The way GEDCOM is structured, that means that there will be an INDI record (an individual record) for John Doe as individual #79 and similarly an INDI record for the other three family members as individuals #80, #81, and #82. Data such as a person's name, birth date, death date, etc. is linked to these INDI records. So for example, the GEDCOM will not say that John Doe was born on 12 Aug 1848, rather it will say that individual #79 was born on 12 Aug 1848 and that the name of individual #79 is John Doe.
I would emphasize that these individual numbers and family numbers don't mean anything except that they are unique within the GEDCOM. They often are not carried forward into a piece of software that is importing the GEDCOM.
Nothing in the INDI records says that John Doe and Jane Smith were husband and wife, nor that John Doe and Sarah Doe were their children. That's where the "families" part of the "individuals and families" data model comes into play. Suppose that this Doe family were the 18-th family exported in the GEDCOM. Then there will be FAM records (family records) for family #18 in the GEDCOM that tie the family together. There will be FAMS (family spouse) records for family #18 which are for individuals #79 and #80 that say that individuals #79 and #80 were spouses in family #18. There will be FAMC (family child) records for family #18 which are for individuals #81 and #82 that say that individuals #81 and #82 were children in family #18. And there will be a FAM record for family #18 for the family as a whole.
Except for perhaps sounding a little techie, this data model perhaps may seem pretty simple and pretty obvious and straightfoward. But there are some interesting implications of the model, both good and bad. For example, birth facts are connected to INDI records and marriage facts are connected to FAM records. So if you look for a marriage record for individual #79 and #80 (John Doe and Jane Smith), you will look in vain. Instead, you have to look for a marriage record for family #18 and you have to observe that individuals #79 and #80 are the spouses in family #18. On the other hand, it means that the marriage record is only in the GEDCOM file once, and it's in the GEDCOM for family #18. It's not in the GEDCOM twice, once for individual #79 and again for individual #80.
Another little curiousity is that Samuel Doe and Sarah Doe are children in family #18, but the marriage fact has nothing to do with them. The marriage fact is really a spouse fact associated with FAMS and is not really a family fact associated with FAMC or FAM. That seems pretty unremarkable for a marriage fact, but it can become really confusing because family census facts really work the same way. They really only work for the spouses and not for the children.
This brings us back to RM. The RM database uses the "individuals and families" data model and it has both individual facts and family facts. Individual facts are such things as birth, death, and burial. Marriages and divorces and the like are not individual facts in this model even though there are two individuals who are parties to the marriage or divorce. Family facts are really spouse facts and they include such things as marrriage, divorce, marriage bond, marriage bann, and the like.
All RM individual facts have one individual who is the principal to the fact. All RM family facts have one family which is the "principle family" for the fact. The family fact is really only for the spouses and not for the children. Being a child in RM is not a fact. Rather, it's implicit in being a FAMC (a family child) for the family. And truly, even being a spouse in RM is not a fact. Rather, it's implicit in being a FAMS (a family spouse) for the family. So marriage is a fact (a family fact) but being a spouse of another person is not a fact. Birth is a fact (an individual fact) but being a child of another person or persons is not a fact.
By contrast, something like TMG does not have family facts. Rather, it has individual facts that can have two principles to the fact instead of one. I'm not sure how to characterize the ancestry.com data model. It certainly doesn't have family facts in the same sense as RM. But I'm not sure it has individual facts with two principles to the fact like TMG. Without being really sure, it looks like the ancestry.com data model is treating marriage as two separate events, one for each of the spouses. But having said that, it obviously must be linking the two separate event together somehow or other.
Finally, we get to shared facts. There is nothing in the old PAF and GEDCOM "individuals and families" data model that accomodates shared facts. So each vendor sort of has to create their own version of the data model for their shared facts. What happens is that there is a principle to a fact - the principle being the person being born, the person being buried, etc., and there can be additional people who have some sort of role in the event. A role for a birth might be a midwife. A role for a burial might be a pallbearer. Generally speaking, the roles can be anything you wish.
So for example, Samuel Doe in our mythical family might have been born in 1872 and the midwife who delivered him might have been Rebecca Williams. So you might share Samuel's birth fact with Rebecca Williams with the role of midwife. Then if you ran a report for Rebecca Williams, it might say something to the effect that Rebecca Williams was the midwife who delivered Samuel Doe in 1872. So even though the event was "Samuel Doe was born in 1872" and you shared the fact with Rebecca Williams, a report obviously would not say that Rebecca Williams was born in 1872. Duh! Rather, a report would say that Rebecca delivered Samuel and that her role was midwife.
RM's implementation of shared facts maintains the limitation that each fact has only one principle to the fact, unlike TMG's model with more than one principle. But RM's implementation of shared facts is extremely flexible about how many people can share a fact and what role each person has. But just remember that a marriage is not a shared fact. It is a family fact in RM. Well, a marriage can be shared. But if so, it would be shared in the sense of somebody having the flower girl role and somebody having the minister role and somebody having the bridesmaid role. Etc.