<p dir="auto">I have one form type (extending <code class="notranslate">AbstractType</code>) which has an option to switch between adding children either as regular fields or as hidden ones. Two instances of that type are created in the controller, one with regular fields, one with hidden ones. Both instances are passed to the template. The form with hidden fields is rendered first, then the other one.</p>
<p dir="auto">That used to work well. But with <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="5620346" data-permission-text="Title is private" data-url="https://github.com/symfony/symfony/issues/4918" data-hovercard-type="pull_request" data-hovercard-url="/symfony/symfony/pull/4918/hovercard" href="https://github.com/symfony/symfony/pull/4918">#4918</a>, the 2nd form isn't rendered at all. I couldn't find out why, as <code class="notranslate">isRendered()</code> still returns <code class="notranslate">false</code> prior to being rendered and it also <code class="notranslate">has()</code> all expected fields. Both forms would also be rendered correctly when changing their order.</p>
<p dir="auto">@bschussek: Do you have a clue what could cause this? Or shall I provide some of the code mentioned?</p>
<p dir="auto"><a href="http://symfony.com/schema/dic/services/services-1.0.xsd" rel="nofollow">http://symfony.com/schema/dic/services/services-1.0.xsd</a> fails validation in both PhpStorm and OxygenXml</p>
<p dir="auto">error is (output from OxygenXml when validating the XSD file)</p>
<p dir="auto">System ID: <a href="http://symfony.com/schema/dic/services/services-1.0.xsd" rel="nofollow">http://symfony.com/schema/dic/services/services-1.0.xsd</a><br>
Main validation file: <a href="http://symfony.com/schema/dic/services/services-1.0.xsd" rel="nofollow">http://symfony.com/schema/dic/services/services-1.0.xsd</a><br>
Engine name: Saxon-EE 9.5.1.7<br>
Severity: fatal<br>
Description: Error in complex type container: Ambiguous content model, there are two xs:any wildcards that match overlapping sets of namespaces<br>
Start location: 20:0</p>
<p dir="auto">and appears to be caused by a duplicate definition of</p>
<div class="highlight highlight-text-xml notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="&lt;xsd:any namespace=&quot;##other&quot; processContents=&quot;lax&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot; /&gt;"><pre class="notranslate">&lt;<span class="pl-ent">xsd</span><span class="pl-ent">:</span><span class="pl-ent">any</span> <span class="pl-e">namespace</span>=<span class="pl-s"><span class="pl-pds">"</span>##other<span class="pl-pds">"</span></span> <span class="pl-e">processContents</span>=<span class="pl-s"><span class="pl-pds">"</span>lax<span class="pl-pds">"</span></span> <span class="pl-e">minOccurs</span>=<span class="pl-s"><span class="pl-pds">"</span>0<span class="pl-pds">"</span></span> <span class="pl-e">maxOccurs</span>=<span class="pl-s"><span class="pl-pds">"</span>unbounded<span class="pl-pds">"</span></span> /&gt;</pre></div>
<p dir="auto">at L 27 &amp; 31</p>
<p dir="auto">net result is that DI container utilising an XML definition won't compile.</p>
<p dir="auto">[edit]<br>
Container definition will compile under most circumstances but if there is a slight error in the xml  that is not caught by the XSD, (XSD is not a perfect tool in and of itself,) then it appears that most of these parsers lose their way.  However, the invalid syntax of the XSD itself is a problem.</p>