Context components with different scope/lifetime

If we think about the stuff we want to put in $context, we can categorize it by scope/lifetime.
(to clarify: by "lifetime" i do not always mean the duration a php variable is defined.)

$world
This stuff can be considered the same in every request, for every user, even in cron jobs. It does change over time, but these changes affect everyone in the same way.
- everything that lives in the database: nodes, users, settings, enabled modules, enabled themes etc.
- everything that lives in the filesystem: source code, available modules,

$user / $session
This stuff can survive more than one request, but it is different for every user.
- the current user id or ip address
- dynamically added user attributes, such as roles, etc.
- the $world from the user's perspective, with things filtered away by permission, groups the user has joined, posts written by the user. It's the world with $uid as an argument.

$php_process
this can be a cron run, a drush command, or a web request.
This is the only category where global state is acceptable, or rather, the natural thing.

$web_request / $web_response / "in between"
user requests a web page. In most cases this is identical with $php_process, with exactly one $user object. But: Imagine we want to produce cached pages for 10 different users in one cron run? So far I don't know of any module that does that, but it would be a good idea to make this technically possible.
During the lifetime of a $web_requests, we have three categories of data (and none of these has to be tied to a $php_process):

1. data that is available from the beginning: the url path, GET and POST, etc. ($request)
2. data that is determined in the process: the current user, the current theme, router item, page callback etc. In our thinking, some of this is $request, and some is $response. Ideally, once we have all this information, we can discard the data from step (1). Simulated requests could start directly from (2).
3. Data that is sent back to the browser. This is all $response.

What is the practical consequence? Do we really want to represent each of these categories with a specific object?
Are there more practical examples than "build 10 pages for 10 users in one cron run" ?
I don't know. But it does make sense to spend some thought on it.