Is your feature request related to a problem? Please describe.

My raidweakauras are usually structured as follows regardless of needing those elements:
Text 1 - Short name
Text 2 - %p
(optional) Border 1, for frame strata reasons it's between Text 2 & 3
Text 3 - %s
(optional) Glow
(optional) Text 4

The reason I include Text 3 %s regardless of needing it, is because I tend to add a Text 4 that gives different info. Without making Text 3 prior (regardless of needing it) it would be inconsistent and make mass edits harder since Text 3 would always represent something different.

Scenario:

Dynamic Group with two auras
- Aura 1 has: Text 1, Text 2, Border 1, Text 3

- Aura 2 has: Text 1, Text 2, Text 3, Text 4

Result in Group - Display: 
Text 1
Text 2
Border 1
Text 3
Text 3 / Text 4

https://i.gyazo.com/20f905588eb839d80af564868817edda.jpg

Describe the solution you'd like

Maybe a forced element order like Text first, then Glows, Models etc... only while in Group -> Display view.

I hoped the above result to be:
Text 1
Text 2
Text 3
Text 4
Border 1

or 

Text 1
Text 2
Border 1
Text 3
Text 4

Describe alternatives you've considered
Making more elements that I don't actually need

Additional context
Add any other context or screenshots about the feature request here.

But how does your solution make anything better? You still need a extra dummy text, don't you?

true but I would only need 1 and the idea was also to get rid off the weird "Text 3 / Text 4" stuff.
Some scenarios also have multiple Text 3 elements instead of them being merged.

So what is the problem with your setup and the current merging algorithm?

My problem is that it while it may be logical, it is not very mass edit friendly.

• I would prefer that a scenario like this:

Dynamic Group with two auras
- Aura 1 has: Text 1, Text 2, Border 1, Text 3

- Aura 2 has: Text 1, Text 2, Text 3, Text 4

displays:

Text 1-4 + Border 1

but instead displays:
Text 1 Text 2, Border 1, Text 3, Text 3 / Text 4 (odd one)

• ..and that a scenario like this:

Dynamic Group with two auras
- Aura 1 has: Text 1, Text 2, Text 3, Border 1, Text 4

- Aura 2 has: Text 1, Text 2, Text 3, Text 4

displays

Text 1-4 + Border 1

but instead it displays:

Text 1, Text 2, Text 3, Border 1, Text 4, Text 4
(the odd part here are the two Text 4 elements, that are identical but not merged)

so basically

"merge elements if they are identical, else create an extra element, and maybe force a certain order like Text first then Glow, then Border.."

instead of

"respect the order that the elements were created in and create an extra element (even if identical to other ones) if the element order doesn't match among auras" (not sure if that's what it currently is doing)

I looked at this for a bit.

First off, the way it currently works is that settings are merged if they are of the same type AND at the same absolute position. That position counts all sub elements not just the eleemnts of the same type.

I do want to keep the order between sub elements the same, as otherwise the behaviour of the up/down buttons would be even stranger.

Now, the current algorithm isn't a particular smart. Conditions and Author Options use a different more involved merging algorithm that tries to align sub structures while keeping the ordering sane.

For the example:
Aura 1: Text, Text, Border, Text
Aura 2: Text, Text, Text

With the Conditions algorithm the 3 texts would all be merged, and simply have a unshared border at the 3. position.

But looking at how the display options are built, I don't want to add it. It's already a pretty complex system that has quite a few quirks. Adding that algorithm is not really easily done and would add a lot of complexity.