InstancedMesh vs merged geometry for partially animated copies

Goal: render several thousand copies of one geometry within a draw-call budget while only a subset of instances changes transform each frame.

InstancedMesh uses one draw call and stores per-instance matrices, but the batch is frustum-culled as one volume and changed matrices require marking the attribute for upload. Merging compatible BufferGeometries also uses one draw call, yet moving one logical object later means rewriting its vertex range or rebuilding the merged geometry.

Because helper names and constructor signatures vary by release, the target is a pinned three.js version whose InstancedMesh and geometry-merge APIs are confirmed first. The unresolved choice is whether to use one InstancedMesh for every copy or split instances into separate batches by update frequency.

Which batching granularity minimizes per-frame cost under this constraint? Is a single InstancedMesh acceptable when most instances never move? Should animated instances be isolated into their own InstancedMesh even if draw-call count rises?