I'll add - it should be an option (and in the HS package manager it is) to distribute some classes/routines as .OBJ and some with source within the same package.

@Evgeny Shvarov there's internal work in the HS package manager to support packaging as a studio project, which may optionally include deployed code. (I believe this didn't make it into the ZPM fork.)

The downside to this approach is that you may need different artifacts for different target platform versions. (It's always safest to assume that you do, at least on the major.minor level.) This would be a new design consideration in zpm-registry.

One possible upside to this approach is that it may be possible to install the build artifact even on environments that don't have the package manager. For the internal implementation we generate an INSTALL.mac that automates things from the different resource processor classes. Uninstallation is still a bit of a conundrum though; I think we'd be better off requiring the package manager for any ZPM implementation of packaging/installing deployed code.

I can think of one extremely valuable internal project that would only be palatable to distribute via ZPM if we didn't have to ship all the source (specifically, a Mockito-style mock framework for ObjectScript that breaks the glass on some internal things not shipped in product source).