Great question!
So, here's the rundown on mods, and files within mods:
1. The base game is parsed first, then expansions, then mods (in general).
2. The names of files are irrelevant in all cases. Name files so that you can find what is in them, but that's the only purpose to a filename.
3. The names of folders do matter a lot, and (as you have correctly done) determine what gets imported where.
4. As you can infer from my prior two statements, you can't overwrite a file in the base game with contents from a mod or expansions. You can only add to them (whole new stuff, or things that are based on the original), or alter stuff.
---
With that being said, obviously sometimes the way you want to alter something is to remove it. Do do that, you need to actually alter the original and say "you're deprecated" or something along those lines.
One reason for the lack of ability to remove things is that sometimes (not in this case, but many others), removing something will cause unintended failures somewhere else. If someone tried to remove VWings, for instance, that would be a dramatically bad thing to try to do directly, because many other things are based on it, and it would affect mod compatibility, etc. Instead, what you'd want to do is alter VWings in a mod so that they are no longer in any of the fleets, or something to that effect. Making them, in effect, "still there but just not used."
In your particular case, there's not a super easy way to do that. But there are two important pieces of xml that you can use to change any particular xml element via a mod:
name="NewEntityName" copy_from="OriginalEntityName" (to make descendants or variants)
and
name="OriginalEntityName" is_partial_record="true"
More in a second on that.
---
I said above that base game, then expansions, then mods get processed, right? That's only... mostly true.
1. First it processes all "original" nodes (no partials, no copy-froms) from the base game, then expansions, then mods. These depend on nothing, so can't fail.
2. Then it parses all the partials from the base game, then expansions, then mods, in a loop as much as it can, until nothing is changing anymore. It's possible for these to fail because they are actually editing a copy-from version.
3. Then it parses all the copy-froms, looping again, and then partials again looping again.
---
In your case, the easiest thing would be for you to make partial records for the things you don't like, and assign them to be things you don't like. So, an example:
(Original file pseudo code)
<name"BrightThingYouHate1" path="path1"/>
<name"BrightThingYouHate2" path="path2"/>
<name"BrightThingYouHate3" path="path3"/>
<name"DarkThingYouLike1" path="path4"/>
<name"DarkThingYouLike2" path="path5"/>
(Your mod file pseudo code)
<name"BrightThingYouHate1" is_partial_record="true" path="path4"/>
<name"BrightThingYouHate2" is_partial_record="true" path="path4"/>
<name"BrightThingYouHate3" is_partial_record="true" path="path5"/>
And then all of the original items remain, but it is then repointing them to versions you like.
---
A few interesting facts:
1. If you were loading savegames or quick starts that used BrightThingYouHate1 in them, and you had removed BrightThingYouHate1, then those would fail to load and you'd have to add it back.
2. If you were loading savegames that used BrightThingYouHate1 in them, and you had simply used a tool to prevent BrightThingYouHate1 from seeding, then those savegames would still have them in there because they had already been loaded. So you'd be seeing it anyhow.
3. But when you redefine BrightThingYouHate1 to be a duplicate of something you like, you run into neither problem and get around it entirely.
That's not to say that the above approach is always the correct one, but in this particular case those are some benefits of it.
---
Further aside:
1. There's I think a "don't show bright backgrounds" setting already. It may turn off the ones you don't like.
2. If that doesn't turn off all the ones you don't like, then you could use that setting in conjunction with a partial record to just set is_bright_background="true" on the ones you don't like (that's not the real flag, but is close enough).
3. That said, that would still have the drawbacks of things showing up in a way you don't want in savegames that were not created on your machine.
Cheers!
