Sections are irrelevant
In short. Sections only serve to group clusters of fields together for usability and UX purposes. From a data perspective, identical field names on one template has never been supported. And even if we can get around this to some extend by referencing fields by their ID, it remains an unsupported practice.
From the dated (but still valid) Data Definition Reference, we learn:
2.1.1 Data Template Fields
A data template field defines the user interface control and other
properties that influence how the field behaves in the Content Editor
and Page Editor. For more information about fields, see Chapter 4, The
Template Field.
Note When defining field names, ensure that they are unique even
between field sections. Both XSLT and .NET code use field names alone,
without reference to sections, to extract content from fields.
Source: Sitecore: How to access same field name in different sections
Furthermore, they are UrlEncoded
Rendering Templates or not; you are really just adding regular parameters to your rendering. The templates gives you a bit better control and allows you to use smarter fields like Droplinks, Checkboxes and so on. But it ends up like this:
And the resulting XML Element in the __Renderings
field:
<r uid="{43222D12-08C9-453B-AE96-D406EBB95126}"
s:par="parameter1=test&parameter2=another%2520test" /></d></r>
Notice how it UrlEncodes it, as Key/Value pairs based on Field Name (not ID).
In Summary
It's by design. Or at least a known limitation that has been in place for as long as I've worked with the product.
Addendum
I realise you're not specifically asking about this (yet), as you're experiencing odd behaviour in the UI. But you're walking on unsupported ground, which is what I wanted to point out. Even if the UI didn't bug out, you would not get the final result you were expecting.
For the record; Sections can be re-ordered. They respect the __SortOrder
field - but it takes a little planning across your templates, to get it right.