After reading Merlin's thoughts on how we need to remove menu_rebuild and replace it with a more straightforward approach, reading the hook_blocks issue, discussing page rendering with pwolanin, pondering on my own thoughts for pipes, liking the canvas-PAC concept that Crell described, here is something big.
On every page request, we create a context. This context contains the path, the loaded objects based on the path, the current user, can contain the rendering mode... Then we call around "hey! here is this request context. I need answers". The answers will be "here is a piece of content. It's configured to go into region X". For speed purposes, I guess we will have "context match" callbacks so that we do not need to call every single former block and page callback on every request. One trivial example is path matching -- notice how block and menu does very similar things for paths. We can then have permission checking -- once again, menu has that with the default access callback and block does something quite similar. And then we could define a node type checker -- it'd be a rather popular one and I guess a very simple one so it's core material. And of course, you would be able to provide new ones. Obviously, these matches all needs to be able to ANDed together.
One last note: currently, on a node type save we rebuild the whole menu router table which is a terrible waste. We could instead just let code hook on the node_type hook and adjust which contexts they want to match. I think the navigation menu based on the router items need to die, it's not a good concept anyways and causes a lot of trouble.
Well, the fine folks at Development Seed even implemented something like your vision on the UI level: http://drupal.org/project/context You just define blocks based on context, not paths :) A forum context is all forum index pages plus any forum topic for example, which you have no way to catch by path patterns themselves.
If you check out the context module, you'll see that it's a bare bones module that pretty much just defines how to set / get context information.
Then take a look at another module in the context package: context UI - it implements the
"hey! here is this request context. I need answers"
part of what you're talking about in your post.
What context UI does best ATM, is defining block configurations that you can trigger if a specific view/node/node type/role etc. is present. Just this feature drives down development time significantly at our site builds.
Of course, not just block configuration but any type of response to a given context is possible. Specific needs? Implement a simple hook and there you go.
I'd love to see Drupal supporting a concept of context along these lines.
-alex