I hope this answer will benefit others that reach that question, because by timestamp alone I think OP solved the problem long ago. ;-)
The post doesn't present immediate solution (I'd need more data from OP for that), but offers some pointers instead.
As mentioned in comments (first by @Rachel), for hierarchical data there's a parent-child relationship.
As with pretty much any design decision, there's the uncertainty principle: hold off with deciding, as long as possible. Implement both and keep them going and see which suits your case better. I should note here I'm not versed AT ALL in WPF, but that sentence:
I see pros and cons for any of the approaches and can not decide which one is better.
strongly indicates laying off decision till you see one approach yields better results than the other will work for you.
Since there's little information about use cases and amount of shared / specific data, I'll propose some things based on assumptions.
Assuming very different, always case-specific extra data
- For each case, create a property file or value objects that can store extra data.
- Add mechanism allowing AppContext to pull said property file / value object in by name / id / other.
- VMs requiring this should be able to tell AppContext to pull that data when they're initialized. This may even be done via naming convention.
Assuming very different, partially reusable extra data
Proceed as in previous case. Why despite this advice I'm marking this as a separate section? Because in cases of just partial reuse I often find it prudent to just skip reuse at all:
- partial reuse tempts, but rarely it really is worth the time spent on thinking "how to reuse it well"
- if you botch the reuse, end-result is rarely maintainable
- newbies coming to code will be quite confused when they SHOULD reuse and when not and HOW to reuse
Bottom line: clarity suffers. If you aren't sure data will be reused, don't bother.
Assuming great deal of extra data, lots of different cases, significant reuse
Split the app. There's obviously too many apps trying to fit here and patterns you identified may be different domains. At this point I'd took a closer look at DDD patterns (especially Bounded Context) and would consider moving the real shared data from IAppContext to supporting domain.