Reading the 1.5 specification it suggests <morph> targets are limited to the contents of <vertices> excluding the <polylist> etc. based elements from inclusion in the logical vertex streams.
If this is the case then why even allow <input> with vertex parameter semantics within these elements? But this is very useful, because otherwise models might have to be broken up into chunks, so <geometry> elements would not even resemble recognizable artifacts from the real world.
So what’s a solution? Something like adding a “symbol” or “sid” attribute to the <polylist> like elements would make it possible to easily match these elements up between morph target meshes. Without a similar mechanism the implementation can only count each occurrence of each element in order.
It’s reasonable for the morphs to all have the same number of positions. Without POSITIONS there is nothing to look at. But the other attributes depend on the materials/effects. It’s not true that they cannot be morphed if they are not completely symmetric mesh-wide. They can be as long as their is agreement. The spec does not require <polylist> like elements to include a <vcount> or <p> element. Therefore they are strictly analogous to the <vertices> elements, except that <vertices> does not contain primitives.
Piling as much as possible into a <geometry> is one way to be able to change its materials easily with <bind_material> on a particular instance. So this ability to extend a mesh to the entirety of what is a logical “object” is useful until a future specification includes a new <object> element, or at least permits <bind_material> inside of <instance_node> so that a node and its descendants can act as de facto objects in lieu of alternatives.