Let me offer some clarity here. The following quoted sentence above from the GitHub issue is causing the confusion:
However, whenever Comet Cache (and ZenCache in the past) are running with user-specific caching enabled, s2Member can allow this to occur, because our plugins do in fact allow for user-specific content to be cached in an intelligent way.
This is not saying that Comet Cache can cache pages that have s2Member shortcodes. I can see how you might be led to believe that based on the previous paragraph that was talking about s2Member shortcodes, however s2Member shortcodes (and conditionals—anything dynamic) simply cannot be cached (even by Comet Cache). They are not cache-compatible. If your home page uses an s2Member conditional, no matter how simple, Comet Cache won't cache the page.
The point that was being made about Comet Cache being able to cache pages when s2Member is running is not referring to caching pages with shortcodes. It's simply referring to caching other pages (that don't have shortcodes or conditionals).
By default, s2Member defines the
DONOTCACHEPAGE constant, which all WordPress caching plugins (including Comet Cache) obey to mean that the page should not be cached under any circumstances (even if the page doesn't have any s2Member shortcodes or conditionals on it). With other caching plugins, no page will be cached when s2Member is active, even if the page is cache-compatible.
However, since s2Member and Comet Cache were developed by the same team, we allow Comet Cache to cache pages when s2Member is running, as long as those pages are deemed cache-compatible (i.e., as long as they don't have any s2Member shortcodes or conditionals on them, which are inherently NOT cache-compatible).