> This is what I mean about being ideological. What benefit do I get from installing two different package managers when one would suffice? It’s definitely not enough to merit doing so.
If you use both Homebrew proper and Homebrew casks, you're already using two package managers. The casks implementation and the formulae implementation have basically nothing to do with each other. They use completely different repositories of 'build' recipes, and they install completely different kinds of packages distributed in completely different formats to completely different places. The installation procedure and the frontend are the only things the two package managers share. The unification of the latter is a thin veneer, since there are various flags and options which apply exclusively to casks rather than formulae or vice-versa.
On the other hand, Homebrew's cask subsystem is basically just a fetcher and runner for installers that already bundle all the dependencies of the apps they install, and in that sense it's not really a package manager.
> Good to know that it is still actually bigger, but that’s really only relevant to me if it’s a superset of Homebrew’s registry,
Pretty much every package repository has some packages in it that are unique to that repository, and so pretty much no package repository is a superset of any other (with the possible exception of downstream forks, depending on how you count things). If you actually apply this standard strictly to any distribution of software, it will almost always mean you can't switch to any other.
> when one would suffice?
For a range of use cases, Homebrew is already insufficient. For example, any program packaged for Homebrew which depends on a Perl library requires you to globally install that library manually via OPAM. Homebrew does nothing at all to help you manage that entire class of dependency, and leaves it to you to install another package manager to do it.