That predicate is for deciding transparency; overloading it to be a) a transparency filter, b) a hitbox/voxel selector and c) a way of returning the results feels like trying to stuff a quart in a pint pot, so to speak.  I don't think reducing the number of method parameters aids usability here.

There's also the consideration that moving the ``useHitBoxes`` parameter into the predicate makes the method signature ambiguously similar to the old API: if you want to pass a null predicate (which IMHO should be a valid thing to do for the common case of "what am I looking at?"), it'll need an explicit cast to ``(Predicate<BlockTargetResult>) null`` to avoid confusion with the old ``Set<Integer>`` methods.  That's just irritating.