FNVEdit shows conflict for injected records instead override

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Please download the attached files. Load them in FNVEdit as:
   FalloutNV.esm
   test1.esp
   test2.esp
2. open the weapon 001735E5. Observe the red/fuchsia colors that highlight a 
conflict.

What is the expected output?
No conflict, just an override. Yellow background and Green foreground.

What do you see instead?
A conflict. The upper index record has red foreground, meaning conflict looser.

What version of the product are you using? On what operating system?
r1859

Please provide any additional information below.
The same scenario works as intended in TES5Edit. So FNVEdit considers injected 
records in a special way.
The records are taken from "TribalPack.esm" and "Grenade Hotkey", but I 
isolated them for simplicity.

Original issue reported on code.google.com by clampa...@gmail.com on 16 Dec 2014 at 5:57

Attachments:

• Test.7z
• Conflict.png

[GoogleCodeExporter]

I have the same think in TES5Edit. It's all fuschia as long as it differs 
between the two plugins. And by the way, in case of override this is as logical 
as the other way around. Without a true master, who's to say test1 is better 
than test2?

Original comment by HuguesLe...@gmail.com on 17 Dec 2014 at 12:03

[GoogleCodeExporter]

Let me throw some thoughts here. The way I see it, in absence of a master, we 
should focus on what we have - the load-order. According to the load-order, 
this is not a conflict, as one record is override by other. Can't be a conflict 
as we only have 2 records, the one with a higher load index will always 
supersede the one with lower load index. The purpose of conflict resolution 
would be to show some conflict, but that requires more than 2 records, with 
conflicting changes. A conflict would mean a change to the original record (the 
one coming from a file with lowest load index) that does not propagate to the 
high-index record.

In my opinion a master is just a file, which hosts a record. Whether the record 
has the ID starting with it's load-order-index byte or not, does not matter.
In our case, the hosting file (1st appearance of the record in load order) is 
test1.

In your vision, injected records are a sort of 2nd class citizen records, but 
from the engine perspective, it does not care which file hosts a certain 
record. All it cares is the load order and which file is higher in said order, 
from the ones that contain a certain record.
I know there are exceptions to the above "rule", for certain record types (NPC 
and NAVM comes to mind). Those are exceptions and can be treated as such.

Original comment by clampa...@gmail.com on 17 Dec 2014 at 2:40

[GoogleCodeExporter]

Some record overrides injected record? That happens maybe once per year, the 
first time I ever see this in my modding life. Spending time on changing 
something that is usefull for 0.00001% of users once a year is not worth the 
time imho.
Btw I agree with Hlp on this.

Original comment by zila...@gmail.com on 17 Dec 2014 at 6:24