I'm using Sling Dynamic Include to optimise the caching of a static site. Certain parts of our site are shared across all pages. For example, the header is created in one place in the repository and every page that need it, includes it using a special component.
We have configured SDI so that the component is replaced with an SSI tag. This works fine and allows us to cache the header as a separate bit of HTML on the AEM dispatcher.
In the SDI configuration, we use the shared selector as the include-filter.config.selector for the particular resource type so when the header is included, we get a request to /content/mysite/en_gb/content/snippets/header.shared.html, so far so good.
the shared selector is added twice. The page still renders correctly but in the request log, as well as the dispatcher cache, we can see /content/mysite/en_gb/content/snippets/header.shared.html (this is fine) and /content/mysite/en_gb/content/snippets/mainNavigation.shared.shared.html (for instances where the mainNavigation snippet is used in the header), as well as /content/mysite/en_gb/content/snippets/mainNavigation.shared.html (for instances where the mainNavigation snippet is included by a page directly).
This leads to unnecessary caching of the same markup.
While SDI is primarily intended for dynamic components, I think this is a valid use case for it.
Before appending the selector determined by the filter.config.selector property, SDI could check if the selector's already present in the selector string. That way, we could nest our components, cache them in one spot and make the invalidation quite simple.
I've had a stab at solving this in https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/5/files, the unit tests might actually be a bit clearer than my description above.