After some time using and thinking about the Repository module, I've come to the conclusion that it's current stated use-case is not the most ideal for structuring your application. Most notably, the method of using an EventBus for communication between Repository instances is flawed. Instead, Repositories that depend on the state of other Repositories should be arranged in a hierarchy (either a true tree, or a Directed Acyclic Graph (DAG)), rather than something like an unstructured Graph as is the current setup.

The inspiration for this change comes from thinking about the application as a whole, and understanding the purpose of the Repository layer and the Repositories within that. Just as the UI screens and their ViewModels only ever passively observe from Repositories, and thereby isolate themselves from the implementation details of the Repository while also eliminating strange communication patterns by enforcing the UDF flow, the same should be true of Repositories amongst themselves. Parent repositories should send their state to children, which eventually flows to UIs, to deeper components within the UI, etc.

Ultimately, it should follow a flow that is something like this:

flowchart TD
    Global["Global State (authentication)"]
    Router
    Repositories
    Screens
    Components
    
    Global --> Router
    Global --> Repositories
    Router --> Screens
    Repositories --> Screens
    Screens --> Components

The extent of changes should be as follows:

• Remove the Repository base classes. Just use the standard ViewModels already available. Each Repository should define its own Events as with any other ViewModel (though there may not be many use-cases for them in Repositories)
• Make the Cached API generic enough such that it could be used in any ViewModel, or even outside of a ViewModel if it needs to be done in a standard suspending function
• Create an out-of-the-box implementation for the Contract and InputHandler that makes it very easy to plug the Cached wrapper into a Repository ViewModel without all the boilerplate required now
• Remove the EventBus
• Rewrite documentation to encourage passing parent ViewModels into the constructor of another, rather than reading from an EventBus

Additional nice-to-have features include:

• Support additional methods of busting the Cached values in the Repository, such as time-based or (depending on platform) based on total size of data stored in the ViewModel