The elytron subystem element is defined as:

<xs:complexType name="subsystemType">
  <xs:all>
    <!-- snip -->
    <xs:element name="policy" type="policyType" minOccurs="0"/>
    <!-- snip -->
  </xs:all>
  <!-- snip -->
</xs:complexType>

Elements of an xs:all may appear in any order, but never more than once.
However, the policy element corresponds to a wildcard resource, suggesting that multiple elements are meant to be permitted, even though the XSD limits its cardinality to no more than one.
That means, if multiple policy providers are created via management operations, the resulting persisted XML will no longer conform to the subsystem schema.

While the existing PersistentResourceXMLDescription-based parser is not sufficiently robust to detect this issue, its proposed replacement (WFCORE-6779) does, and this subsystem fails to parse its own unit test XML.

As I see it, there are 2 possible solutions:

• Modify the <xs:complexType name="subsystemType"/> to group child elements via <xs:sequence/> instead of <xs:all/>. Unfortunately, the subsystem's own unit test XML contains subsystem child elements in an order inconsistent with its PersistentResourceXMLDescription, suggesting that these child elements should remain unordered.
• Use wrapper elements around any repeatable elements preserving the xs:all semantic validity of the container element, e.g.

    <xs:all>
      <!-- snip -->
      <xs:element name="policies" minOccurs="0">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="policy" type="policyType" maxOccurs="unbounded">
              <!-- .. -->
            </xs:element>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <!-- snip -->
    </xs:all>
    

If I am mistaken, and only one policy provider is permitted, then this would otherwise need to be enforced by the management model.