This classes does not define any method that is not in one of the interfaces. This means you don't need to make it extensible: the new BinaryVector class could implement all this interfaces (re-using the underlying C functions).

In the library, I used MongoDB\BSON\Binary type in the builder, but I would change it to use BinaryInterface. Why this interface doesn't extend MongoDB\BSON\Type?

The interfaces were never very useful for PHPC. One of the original use cases was have an embedded object masquerade as a UTCDateTime and incorporate a timezone, but the benefits are mainly for userland applications.

I think sharing a single Binary class is ideal for anything that would expect the BSON type, and avoiding a separate BinaryVector child class seems like it'd make things easier for users (and simplify what comes back from BSON-to-PHP conversion).

Do we want to return VectorType here?

Yes, once this method is moved to the MongoDB\BSON\Binary class.

Reminder to remove this since we benchmarked both implementations and this was worse.

I think distinct factory names fromInt8Vector, fromFloat32Vector and fromPackedBitVector would make sense if we can provide array types list<int>, list<float>, list<bool|0|1>

AFAIK there's no prior art for using Psalm type hints in stub files. I'm not familiar with how PHPStorm parses the stubs, but would these have a significant benefit for developers? For instance, would they be able to influence Psalm's analysis of an app?

Also, does this mean we prefer factory methods on Binary in lieu of factories on the vector type enum? Either way I expect we'll get a Binary::fromVector() method.