一つのパッケージで、１００近いブロックというのは驚きですね。
参考にですが、１つブロックで、設定を変えて１００の挙動というのではだめなんですか？

ちなみに、他のパッケージのモデルを横から使うことはできますよ。

設定やパラメータでViewを切り替えるのもNGな設計にしているので
（例えば照会と入力は別のBlockにしています）
1つのBlockで複数の挙動をと言うのは今回は採用できないですねぇ(^^;

今回は共通modelとcontrollerを持つPackegeと
それ以外のある程度の塊で分けたPackegeにするべきでしょうね。

アップデート時にブロックが増えるケースが思いつかないので事例をお伝えできないのですが、インストール時にブロックを追加するものはたくさんあると思います。

public function install() {
$pkg = parent::install();

// install block
BlockType::installBlockTypeFromPackage('block_name', $pkg);
}

これと同じことをupdateメソッドでやれば行けると思います！

作成班と検証班でわかれて作業をしていて、Packegeの更新のたびに
アンインストール・新規インストールを繰りかえしていて、
そのたびにBlockが消えてしまうので、検証班が音を上げてしまいました(^^;

今、Packege.php を読んでいたのですが、interfaceにはinstallとuninstallしかないようですね。

interface Installable {

public function install();
public function uninstall();

}

管理画面でアップデートが実行された時に、BlockListを読み直して
refreshしているようですが、BlockListに追加するタイミングがないような気がします(^^;

public function upgrade() {
Package::installDB($this->getPackagePath() . '/' . FILENAME_PACKAGE_DB);
// now we refresh all blocks
$items = $this->getPackageItems();
if (is_array($items['block_types'])) {
foreach($items['block_types'] as $item) {
$item->refresh();
}
}
}

updateじゃなくてupgradeメソッドでした。。
やったことはないですが作成したパッケージのcontrollerでupgradeメソッドを継承してブロックをインストールすればいいと思います。

あぁ、そうですね！
Upgradeメソッドを継承して、InstallBlockをしてから本来のUpgradeメソッドに処理を返せばいいですね！

色々考えた結果、共通Packegeと各機能ごとのPackegeに分けて、
あらかじめ使うであろうBlockを先に枠だけ作っておくようにしました。

ありがとうございました！