Where does an asynchronous operation (status) belong in Application Design Patterns?

Say we want to make an application containing the following:

• Asynchronous and time consuming operations
• Information of these operations progress and status. (e.g. 90% done, reconnecting, etc.)
• The ability to show this information in multiple views, and update UI elements accordingly. (Progress bars, disable buttons for already triggered operations)
• The ability to cancel and pause these operations from multiple views.

Then my question is the following:

Where does these operations and their progress/status belong in an Application Design Pattern?

Decoupling the Service Layer or Network Controller from the View and Model in a design pattern like MVC or MVVM is quite straight forward, as long as you don't provide more UX feedback than a spinner when there's an active network request.

But when I am working on an application confirming to the criteria above, I always end up either

• Not allowing the user to change view during an operation
• Tagging operations with the id of the object currently processed and passing this to the views, or looking in the Network Controller directly from the views/view controllers
• Creating a separate entities for operations, and suddenly I have a request operation in my model

So obviously there are (very smelly) ways to come around this, but they all feel dirty and not inline with how the patterns are intended.

So purely from a software architecture and design pattern point of view, how would you approaching this?