TYPO3 Core

any ideas already on how to solve this issue or did you just file it as a note?

This would be possible using the cachingFramework using cache-tags. It's already available in 4.5 but must be explicitly enabled.
Currently a page has one tag "pageId_...". When a CONTENT-object is rendered we could add tags like "pageId_..._colPos_...".

For the above mentioned example this would mean what we might have a page with "pageId_10" but also "pageId_2_colPos_1". So whenever something changes in that column it would be clear this page is affected as well (and would need to have a cache-clear triggered).

For a scenario with content-sliding we might have content only in the content on the main column - but if ever content is added on a page inbetween we could knowe we'd need to trigger a clear as well. This chain of tags would need to be built up to the point where the first content is found (as far as the slide needs to go). (Similar but different if collect is used.). So a rootline 1 > 2 > 3 > 4 with content on 1 and a cache for 4 we'd then have "pageId_4 pageId_4_colPos_1 pageId_3_colPos_1 pageId_2_colPos_1 pageId_1_colPos_1".

it's a bit hard to understand from your description but I think I know what you're trying to do. Sounds like a nifty plan to me.

Currently there seems no easy way for a content-element being rendererd to return other data than it's actual output.

Looking at the CONTENT-object (TYPO3\CMS\Frontend\ContentObject\ContentContentObject) I found things like
$GLOBALS['TSFE']->recordRegister[$originalRec]
While in general it's no good idea to pollute the global space further sigh how about we'd create
$GLOBALS['TSFE']->recordMetadata
and have an entry for each rendered content-element (identified with the usual $table:$uid) that wants to write there which could for now write to an array
$GLOBALS['TSFE']->recordMetadata[$originalRec]['cacheTags']

During the render-process we already have all overlays processed etc. anyhow. And it would be quite lightweight to add this functionality to contentobjects where that funtionality would be used. Before writing the page to the cache that information could then be collected.

Side-effect of a metadata-array: objects could also return things like "cacheTimeout". And if they do, we could take the smallest value into account to find the minimal page cache-time (although we still need to consider other factors like currently invidible elements that will shortly after become visible etc.).

I know this still might not make the cache-clearing-topic "complete" - but might be one more step.