Because you would see the output (theoretically in the order that the mods are loaded in) to see which mods are making changes to what entries - both which ones made changes, and which one was the last modification and hence the (theoretically) active one. While this then may report a massive bunch of information that is essentially false positives but it would also show when a mod is unexpectedly changing something that you didn't realize or conflicting with something that you didn't think it would.

At that point you'd be hoping to see the needle despite the haystack. The amount of false positives would make it very difficult to spot undesirable changes, unless you already knew what to look for (in which cast you don't need to dump every override).

That said a mod author needs to avoid conflicts with game structures. But the cs should handle that side of things. So we are back to collision between mods.

Or am I missing something?

What you are calling "collisions" and "conflicts" is exactly what a mod is. GameFileA has records FooBar and FooBaz. GameFileB has records FooBar and BarBaz. How are you supposed to know if GameFileB is a mod for GameFileA, GameFileB is conflicting with GameFileA, or the user actually wants GameFileB's version of FooBar instead of GameFileA's? It's only a conflict if, given other changes the two GameFiles do, the two together produce undesirable gameplay results (in which case, another GameFile would need to be created that overrides certain records from both GameFileA and GameFileB to make desirable results).

Because you would see the output (theoretically in the order that the mods are loaded in) to see which mods are making changes to what entries - both which ones made changes, and which one was the last modification and hence the (theoretically) active one. While this then may report a massive bunch of information that is essentially false positives but it would also show when a mod is unexpectedly changing something that you didn't realize or conflicting with something that you didn't think it would.

At that point you'd be hoping to see the needle despite the haystack. The amount of false positives would make it very difficult to spot undesirable changes, unless you already knew what to look for (in which cast you don't need to dump every override).

You do, though, even if you do know what you're looking for, because the current way of searching is to open up every single mod individually in the CS or OpenCS if you aren't sure where you're looking for it. If you're trawling through this, you probably have a pretty good idea of the records that could be at issue. The problem is that you won't know which files contain those records. At present, to determine that, you have to load each and every file individually in an editor and see if it changes any of the small handful of relevant records. This is, to put it mildly, a massive goddamn nuisance. The output wouldn't mean no loadout testing needed, but it would mean that we could fairly reasonably figure out where problems encountered in testing stemmed from so they could actually be fixed.

That's a help. Definitely better than what I currently try to do (and quickly give up on).

The thing is, though, I don't so much need to find what records a certain mod has as which mods have a certain record, specifically among loaded mods, which are rather a lot fewer than I have installed in my OpenMW Mods folder's various subfolders. And the number loaded is still rather high. So that's a great tip and greatly appreciated, but I'd still really, really appreciate something more like originally described and organized in a way that makes it not a pain to search for a specific record (because when you run into a bug, the record can be figured out in-game for the most part, where the specific mod file can't).

The thing is, though, I don't so much need to find what records a certain mod has as which mods have a certain record, specifically among loaded mods, which are rather a lot fewer than I have installed in my OpenMW Mods folder's various subfolders. And the number loaded is still rather high. So that's a great tip and greatly appreciated, but I'd still really, really appreciate something more like originally described and organized in a way that makes it not a pain to search for a specific record (because when you run into a bug, the record can be figured out in-game for the most part, where the specific mod file can't).

Honestly, I'm not sure that would belong as part of the game, but I can definitely see it as an ancillary tool. Levelled list mergers (like omwllf, if you don't mind the shameless plug) do essentially this already, just limited to the various levelled list records.

It should be fairly straightforward to take a levelled list merger as a starting point and expand it to dump a list of all colliding records. With the caveat that others have mentioned that the majority of records in a mod are explicitly and intentionally collisions with something from a master file.

In terms of users managing conflicts between mods, which I think is the aim of the tools proposed in this thread, giving LOOT Morrowind compatibility so we're not stuck with handmade rules-based tools like MLOX for load order tweaking, would go a long way. People are actively working on giving xEdit Morrowind support, so hopefully stuff like Mator Smash should become possible soon, which will also help. Beyond stuff like this, though, I'm pretty sure you need to really know the intentions of the authors of two mods to work out which conflicts are benign, which break things, and which can be worked around by changing one of the mods.