cache-identifier for content-nodes

[PRGfx]

From my understanding, the content is only cached by the name of the @process configuration, so it is not really viable to use it for normal content-elements.

I could imagine a system of configuring a custom cache identifier, i.e. passing it down to the RenderPath prototype:

@process.ajaxify = Psmb.Ajaxify:Ajaxify {
  entryIdentifier {
    ...
  }
}

with some default values:

prototype(Psmb.Ajaxify:RenderPath) {
  @class = 'Psmb\\Ajaxify\\Fusion\\RenderPathImplementation'
  entryIdentifier = Neos.Neos:DataStructure {
    node = ${node}
  }
}

and the RenderPathImplementation building the entryIdentifier from the existing key and the (non-nullable, stringified) identifier parts.

Is this a sensible approach or am I missing something and this isn't even actually necessary?

[PRGfx]

I played around a bit with a more dynamic cache identifier and that works fine in itself, however I am now aware, that the rendering (root.ajaxify) does of course not know the content-nodes and I'm not sure how best to "recreate" a contex.
As this is all basically just a caching layer, I think the wording from the caching context would make sense (entryIdentifier, context). So maybe a Ajaxify component which serializes a context as the fusion runtime (or rather the ContentCache does). Unfortunately I don't see good ways to re-use any of this and I'm not sure rebuilding this behaviour makes sense at this point.

Any other ideas on how to achieve this?

If there is a node != documentNode, I could go for a more low-budget solution of storing that identifier and getting it from the document later, I think, but that feels like it will be limited with the next use-case.

[PRGfx]

With 8811c03 I drafted a concept on how to handle dynamic cache-identifiers and how my approach could be used with content-nodes. However it does not satisfy my concerns regarding other rendering-relevant context variables: it only includes the content-node in the ajax request and exposes its contextPath doing so.
Because of that I won't open a PR for now, but will leave the fork as an example.