Ah, phew. I was wondering why it seemed so confusing.

It probably could be implemented better, yeah, maybe the way you described, but I'll be honest that the implementation here is probably at least partially thanks to my inexperience with C++. I'm not exactly sure how I'd go about doing what you just described. But it's probably better than the implementation I have here, esp. if it would allow me to rework item group to just have a list of "nodes" instead of having to go through two lists independently.

I'm still trying to figure out what to do about the recursion check. The on access check here is what's really making an identical interface impossible, but there's complications when doing it with on-add, the other idea I was considering (there's no guarantee things will be added in any particular order at the moment, and introducing one would be difficult and problematic) and I really am keen on keeping consistency checks encapsulated rather than relying on an outside bit that may be rewritten later to enforce it. On-access is guaranteed to throw an error message when a problem is encountered and go on to behave "appropriately", but obviously isn't useful from a development standpoint. 

Of course, I could just add the recursion list argument to the Item_group_entries get() as well, and bring the interfaces together that way.

I'll have to spend some more time thinking about it, but I think there is in fact a better potential implementation here. (Of course, thanks to encapsulation, I can just rewrite that whenever, the Item_group class is the only one with an interface used in the rest of the application)