Totally agree with Quentin: wix multi-refs were designed for n-m relationships (1 actor plays in many movies/ 1 movie has many actors) , a problem that is traditionally solved by a 3-rd table (in relational terms).
I also avoid them like the plague, but for another reason than Quentin mentioned: if you ever want to port your app to another db/another programming env., you will have enough problems. But changing your db-setup will kill you. And the wix-solution (multi-refs) is not supported by any other db.
So if I understand you correctly, and want to use a “looking-downward” approach (from 1 to n), don´t. Go traditionally (looking upward, every n carrying the _id of the “One” (slight pun intended)).
EDIT: reading my own answer back. Not clear enough. Multirefs were introduced in Wix to solve the n-m problem explained above: how do you circumvent the introduction of the 3´rd table in a graphical, click-your-way-out-of-a problem, environment like Wix (Wix always has had a hard time choosing between developers and non-devs). Solution: multi-refs: at actor level you keep track of all his movies, at movie-level you keep track of every actor, thereby avoiding the problem of the introduction of the 3-rd table (actors/movies).
For developers, there is NO NEED to use multi-refs, it was introduced for non-devs. It only mimics the n-m relationship without the use of the 3-rd table. Because of all the problems mentioned above, developers should steer clear of using multi-refs, it introduces more problems than solutions.