<div dir="ltr">Just to add my 2c to the "to split or not to split" topic: Please do not split such a fundamental package! As already mentioned, it is the 2nd most used package on Hackage (only slightly behind "bytestring" and ignoring "base"). Even making tiny incompatible changes will immediately break hundreds, if not thousands of packages on Hackage. If this is really planned, there should be an extremely good reason for it, and I can't see one: The package is very small and there is almost no activity in the repository (<a href="https://github.com/haskell/containers/graphs/commit-activity">https://github.com/haskell/containers/graphs/commit-activity</a>), so maintenance burden can't be a valid reason for splitting. And even if it one wants to split, there are lots of orthogonal aspects of containers: lazy/strict, order-based/hash-based, set/map/multimap, sorted/unsorted variants, catenable or not, etc. Which of these should be the splitting criterion? The extreme of putting each data structure into its own package seems to be a little bit excessive.<div><br></div><div>OTOH I'm all for adding missing functionality to "containers", at least if they don't introduce incompatible changes.</div><div><br></div><div>Of course one can add additional packages with subsets of "containers", keeping the latter untouched. If most Hackage authors switch to the new packages, "containers" can be phased out. But even if that happens (which I doubt), this will take quite a few years.</div><div><br></div><div>Cheers,</div><div>   S.</div></div>