E.g. looking at AbstractCacheStoreConfig it has the following schema-generating annotation:
@XmlType(propOrder=

)

In resulting schema this translates to:

<xs:complexType name="abstractCacheStoreConfig">
<xs:complexContent>
<xs:extension base="tns:abstractCacheLoaderConfig">
<xs:sequence>
<xs:element name="singletonStore" type="tns:singletonStoreConfig" minOccurs="0"/>
<xs:element name="async" type="tns:asyncStoreConfig" minOccurs="0"/>
</xs:sequence>
...
</xs:extension>
</xs:complexContent>
</xs:complexType>

The xs:sequence element enclosing "singletonStore" and "async" enforces the ISPN xml configuration to have these cache loader elements defined in this particular order.
In other words this would be a valid configuration snippet:
<loaders shared="true" preload="false">
<loader class="org.infinispan.loaders.file.FileCacheStore">
<properties>
<property name="location" value="${java.io.tmpdir}"/>
</properties>
<singletonStore enabled="true" pushStateWhenCoordinator="true" pushStateTimeout="20000" />
<async enabled="true" flushLockTimeout="15000" threadPoolSize="10"/>
</loader>
</loaders>

Whilst for this one the validation would fail:
<loaders shared="true" preload="false">
<loader class="org.infinispan.loaders.file.FileCacheStore">
<properties>
<property name="location" value="${java.io.tmpdir}"/>
</properties>
<async enabled="true" flushLockTimeout="15000" threadPoolSize="10"/>
<singletonStore enabled="true" pushStateWhenCoordinator="true" pushStateTimeout="20000" />
</loader>
</loaders>

The two configurations are semantically equivalent and there's no point in enforcing this ordering constraint on users.

This is just an example of sequence enforcing, but the same thing appears in many places in the generated schema.

A solution might be using the xs:all (vs xs:sequence) xs collection type (where possible):
http://www.w3.org/2005/07/xml-schema-patterns.html#Collection