I haven’t been looking at this as “reverting a feature”, but rather “fixing a backwards incompatibility” that was introduced in a non-major version change. @mogoodrich highlighted a couple of cases where method signatures have changed between 2.0 and 2.1 I believe, and functionally things are different.
What I would think might make sense would be to aspire to maintaining full backwards compatibility, performance, intent, etc. of the Cohort object from 2.0 and before, and to maintain the same functionality as we introduced into Cohort in 2.1 in a new subclass called DynamicCohort or DateRangeCohort or something.
For 99% of implementations and downstream code, this will be a bug fix. For the small number of downstream modules or implementations that use the new features of Cohort, they’d need to update things to use the Subclass instead.
That said, neither Mark nor I will have have the bandwidth to lead this in the near term, and we have found a way to mitigate the current performance issue which makes it less critical (until the next issue crops up). But this is what I was thinking…