I don't know exactly how you would like that to work. Currently it works like this:
If you use {node_view_gui} in some of the node/view/*.tpl and overrides loaded by the content/view module, the {node_view_gui} will be cached by the view-caching. This is because the whole view is cached.
If you are using {node_view_gui} in the pagelayout or included templates, you should add a cacheblock around the code that is fetching/generation information from the database. I typically use cache-blocks for menus and similar elements in the pagelayout.
But like this - provided you want to fine-tune the way you use cache-blocks with subtree_expiry - there's no equivalent to the smart view-cache clear feature that clears dependent nodes' view-cache and so on... (Dependent nodes = object-related ones for example).
This leads to less accurate cache-block handling...
Yes, you are right. The all of the cache-blocks are automatically invalidated upon content-publish. You can however restrict it with the subtree_expiry and the ignore_content_expiry parameters. But it is as you say, less flexible than the smart-view-cache-system.
Do you have any good ideas on how to implement something similar for the cache-blocks?
Well, the only work-around I found fo far is to add the $node.object.modified time of the related object to the keys of the cache-block.
Like this, once the related object is modified, the cache-block expires and a new one is built. It works fine so far for most cases. But if the related-object as itself related-objects, and that the node_view_gui displays or has any relation with those re-related-objects (wow), it might not work as we expect.
I see your point. It would be useful if the cache-blocks supported this somehow. Currently I do not have any good ideas for how this can be implemented. Anybody have any good ideas?