Roster: Relation Name Lookup

> isn't it a little bit over engineered

I suppose some may feel so. I tend to use libraries like project-level traits: reusable components to prevent duplicating code. In this case the concept was developed on a project using Firestore (NoSQL) where joins are not possible so looking up a single field for related items can be very costly. The flip side is that bulk reads of subcollections are cheap, so being able to load and cache the field all at once is a huge performance gain.
For sure there are other ways to handle this, but I think regardless of your backend database this will be the most efficient for 95% of the scenarios that match the description.