That's a good observation and something I thought about quite a bit when writing this. This version of entity mirroring does not model hierarchical relationships. For example, if an account was part of a team which was part of a league, the account would have to return the team and the league as its super entities.

With your suggestion, I could recurse up the super entities and still save the league as a super entity of the account, however, I was not sure if that was the best choice. A league may actually not be a super entity of an account, and I figured I could instead provide the user with full control over what entities are actually super entities.

This is quite cumbersome for hierarchical things like superior relationships. In this case, it is up to the user to go up the hierarchical chain when returning super entities to sync. This will solve the problem in your question and still allow you to return all employees under a manager, however, it loses the information of how far down the chain they are.

For all of our immediate application needs, we don't do any sort of hierarchical-based filtering (such as filtering the accounts one level below a manager). However, it is trivial to add this in later on and provide an optional flag to allow users to filter sub and super entities by their level up or down the chain. Adding it later on would also not affect any of the base code (with the exception of changing how you return super entities)

Hope this explanation makes sense of my reasoning behind avoiding any recursive stuff out of the box