I think a good place to begin analysis is to take a look at ACES.
Ignore the actual feature set (which is pretty decent), my point is to
look at process. ACES is a bunch of changes and additions to the base
ACS, and the result is a different toolkit. It can't be distributed, as implemented in 3.4.x, as an alternative install or a "glue" package
on top of standard ACS 3.4.
This is not the right approach. I think we can start by stating that vertical packages that are built on OpenACS 4.x should be layered on the stock acs core. Modified packages (say a customized bboard) can be offered as replacements for the standard packages, but in the package scheme there's no reason why customized versions of non-core packages can't be released as (say) "aces-bboard" etc. The "glue" package would automatically install the blend of standard and customized non-core packages that are required.
ACES will provide us an interesting test case. There will be an OpenACS 4.x version of ACES at some point. Since this code base exists in 3.x and since ACES is really useful, it will undoubtably be our first vertical application package built on 4.x.
It is also a fairly well-defined space so we can concentrate more on central issues like how to structure such packages, how to ensure we can install them on top of vanilla OpenACS 4.x releases rather than see the core fork, etc rather than the feature set it offers.
