Typically a controller is able to keep a view around (rather than disposing and creating anew) a view via this.reuse('name', Constructor, opts), where opts is an object.
However, if opts differs from the previous time reuse is called (as dictated by _.isEqual which is what Composition.check calls under the hood), then the invocation will cause the view to be disposed and created from scratch.
Thus, in order for it to be used properly, the View options hash should not contain dynamic information as it will cause the view to always be re-created. An example where this may come up is a paginated view where the query params could be passed in so that the view can update parts of the itself to reflect the updated query (such as the current page number, search query, etc.).
Obviously (or not), this dynamic information should be stored on the model/collection and can be done via overriding/enhancing the update call (such as fetch) via re-declaration with appropriate logic (like creating a property on the data store such as currentQuery) and a super call or via AOP with some Flight advice-like flow or with events.
This leads to having said dynamic information on either the controller or data store (model/collection), but it's probably a better idea to have it placed on the data store which the view can have access to and doing the proper enhancements, rather than having the controller maintain this logic.