I've found surprisingly little information about how to define your stores when building an app with react & flux (specifically Fluxxor). My co-workers, most of whom have experience with Backbone and other MVC frameworks, tend to create stores that are basically collections (ie. BlogPostStore, CommentStore). My gut is that stores are very intentionally not called collections or models. In the flux docs, stores are explained to be both collections and singletons representing a logical domain, without really explaining when you should use one form or the other.
Are there best practices or rules of thumb for deciding when you should be defining stores that are basically collections or more specific singletons?
The best way to divide stores when using flux is, in my opinion, around domain concepts. Need to manage blog posts and comments? A blog post store and a comment store (which each act as containers for a collection of their type of data) makes sense. Have a session with authentication data that you need to manage via client side actions? A session store — which wouldn't manage a collection at all, just a bunch of session-related data — is perfectly legitimate. The TimeStore mentioned in the documentation you linked to is another great example.
Basically, any time you're dealing with a new "type" of information that doesn't fit in with an existing store, create a new one. (There was a talk a couple years ago where someone from Yahoo! said they had an app with more than a hundred stores.) Then, in the stores themselves, implement the action handlers for whatever type of data management you want; if it's a store that handles a collection of something, then the action types and handlers you define will reflect that. If not, that's fine too.