Our sphgeom provides a nice generic interface for spherical pixelizations, with implementations for HTM, Q3C, and a custom modification of Q3C. By delegating the work to the public HEALPix C++ library, we could easily add HEALPix to the mix, and write downstream mask manipulation code without assuming a particular pixelization. It'd also give us an easy way to compare the performance of different pixelizations.
The stack already includes healpy as a dependency, which builds against the HEALPix C++ library internally. Since healpy can also build against an external HEALPix library, we should create a new third-party LSST package for that and have healpy depend on it. We should then either make HEALPix an optional dependency of sphgeom or (probably better) put a new subclass of sphgeom::Pixelization in a new package that depends on both HEALPix and sphgeom; we want to make sure the current sphgeom functionality continues to be available without additional dependencies.
It looks like the tricky part of implementing that new Pixelization will be determining whether the pixel method can just return a sphgeom::ConvexPolygon with the four vertices of the pixel (i.e. under what conditions do the non-geodesic HEALPix boundaries extend beyond the geodesic boundaries of a ConvexPolygon with the same vertices instead lying completely within them). I've only taken a quick glance, but it looks like the HEALPix library includes routines for directly implementing all of Pixelization's other virtual methods.