Mousetick

Good question. I'm not aware of an easy way to navigate nested objects back and forth in xEdit. I wish there were 'Back' and 'Forward' shortcuts, and a history of viewed records, like in a web browser. Personally I write down the form ID of the record I'm viewing before drilling down the hierarchy, so I can go back to previous records later. It's a cumbersome hassle. Another way to navigate back is by using the 'Referenced By (n)' tab at the bottom of the record window, but it can list several possible paths back which doesn't really help.
About your other questions, let's drill down the list chain from your example, and then go back up, the way the game would work:
Belethor's Merchant Chest requests up to 15 items from LItemMiscVendorArmor75 [LVLI:0009AF07].
LItemMiscVendorArmor75 [LVLI:0009AF07] requests one item each from 5 sub-lists, one of them being LItemArmorCuirassAnyTown [LVLI:0001674E]. LItemArmorCuirassAnyTown [LVLI:0001674E] requests one item each from 2 sub-lists, one of them being LItemArmorCuirassHeavyTown [LVLI:00016747]. LItemArmorCuirassHeavyTown [LVLI:00016747] contains 16 entries, some of which are individual armor pieces, others are more sub-lists. The list has the 'Calculate from all levels <= player's level' flag. If the player is level 10 for example, the game will randomly pick an item among the first 8 entries from Level 1 to Level 8, rather than pick the Level 8 entry (closest to, and not greater than, level 10). Thus the list may return a low-level Iron Cuirass, even though the player is level 10 and better Banded Iron Cuirasses are available. The list has the 'Calculate for each item in count' flag. This has no effect here, because only 1 item is requested from this list. The list contains 4 identical entries for Iron Cuirass at Level 1. This is intended to increase the probability of returning an Iron Cuirass. This makes the Iron Cuirass 4 times more likely to be picked than if it were listed only once. One item has been selected from LItemArmorCuirassHeavyTown [LVLI:00016747]. Repeat the above steps for the other sub-list within LItemArmorCuirassAnyTown [LVLI:0001674E]. Then we're back to LItemArmorCuirassAnyTown [LVLI:0001674E] which now contains one randomly selected Heavy Armor Cuirass and one randomly selected Light Armor Cuirass. The list has 'Calculate from all levels <= player's level' flag. See above. The list has the 'Calculate for each item in count' flag. This has no effect here, because only 1 item is requested from this list. Repeat the above steps for the 4 other sub-lists within LItemMiscVendorArmor75 [LVLI:0009AF07]. Then we're back to LItemMiscVendorArmor75 [LVLI:0009AF07] which now contains one randomly selected Cuirass, one randomly selected Boots, one randomly selected Gauntlets, one randomly selected Helmet and one randomly selected Shield, of various qualities/levels. The list has the 'Calculate from all levels <= player's level' flag. See previous. The list has the 'Calculate for each item in count' flag. As the vendor chest requests 15 items from this list and each entry in this list has a quantity of 1, this causes 15 random separate item selections, rather one single item selection multiplied by 15. For example, the list may return 3 shields, 2 boots, 4 cuirasses, 1 gauntlets and 5 helmets. If that flag wasn't set, it could return 15 identical helmets, or 15 identical boots, etc. The list has a 'Chance None' value of 25. There is a 25% chance the list selects nothing. As the 'Calculate for each item in count' flag is set, this applies to each random selection. So in the best case the list will return a total of 15 items to the chest (0.75^15 = ~1.3% chance of happening), and in the worst case, it will return 0 items (0.25^15 = about 1 chance in 100 millions, practically never), with an average of 15*0.75 = ~11 items selected across all draws. You can use the Creation Kit to see how the leveled list behaves inside the chest:

Enter the list Form ID in filter field. Double-click the list found. In list panel, enter desired player level and number of items. Click 'Preview Calculated Results'. See also https://en.uesp.net/wiki/Skyrim:Leveled_Lists.

This is a vast and complicated subject, even more so when WACCF is used.
I'm surprised by your observations about loot. The approach you took to resolve specific leveled list conflicts should have no significant impact on the quantity of loot you find. In most cases, the edits that the aforementioned mods (WACCF, CACO, CCOR, AMB CA) make to leveled lists only affect the type of loot per level, not its quantity.
For humanoid NPCs, the quantity of loot is determined by their inventory (defined in NPC_ record) and outfit (defined by OTFT record referenced by NPC_ record). For creatures and animals, the quantity of loot is determined by their death items (defined by DeathItem[...] leveled list referenced by NPC_ record). For chests, the quantity of loot is determined by their contents (defined by CONT record, itself referencing Loot[...] leveled lists). CACO does make a lot of changes to some of the above but they're balanced and designed to work with the overall alchemy/cooking overhaul, and they typically don't conflict, so let's put it aside. Other than that, WACCF, CCOR and AMB CA either don't directly edit the above, or they edit them without changing the quantity of items found.
The leveled lists that WACCF, CCOR or AMB CA touch are typically referenced indirectly and they return only 1 item per level. Even if they were incorrectly merged with vanilla, or with USSEP changes, they would contain the wrong type of item per level, but they would still return only 1 item per level.
I suspect that the "too much loot" behavior before changing your patching methodology is caused by something else. The "much reduced loot" behavior you observed after might be a coincidence - it's hard to say.
But instead of trying to reason in generic terms, I find it easier to look at specific examples using the latest version of all mods:
LItemGems [LVLI:00068525], LItemGems75 [LVLI:001046E3], LItemGemsSmall [LVLI:000F961D], LItemGemsSmall10 [LVLI:0010E0E0], LItemGemsSmall25 [LVLI:001046E2], LItemMiscVendorGems25 [LVLI:0009AF0C], LItemMiscVendorGems100 [LVLI:000C44A7] Conflict between CACO and CCOR: both mods' additions should be merged, otherwise one or the other won't ever be found in loot or in merchant's inventory. It may look like the list contains more "stuff", but it still returns the same quantity of items per level. The quantity is determined by whatever is referencing those lists, not by the lists themselves.
The fact that both kryptopyr mods conflict and no patch is provided by kryptopyr is a bug. The bug was reported and acknowledged more than a year ago (see "Gemstone levelled list incompatibility with CCOR" in CACO bug section).
LItemEnchArmorLightGauntlets [LVLI:000B4223] and LItemEnchArmorLightGauntletsNoDragon [LVLI:000FDA14] Conflict between CACO and AMB CA: both mods' additions should be merged, otherwise CACO's unique enchanted alchemy gloves won't ever be found. Same as previous.
Likewise, looks like a bug to me.
LootCitizenChildToysList [LVLI:001046E7] and LootCitizenChildToysList75 [LVLI:001046E9] Conflict between WACCF and CACO: both mods add their own version of BugsInJarList, only one of them should be kept. Doesn't matter which one, as their contents are identical. CACO is one kryptopyr mod that (strangely) doesn't require WACCF, so it duplicates WACCF here. If you keep both BugsInJarLists you'll find a Bug In Jar item twice as often as if you keep only one, but you'll still find the same number of Bug In Jar at a time. This list is referenced by children NPC inventories, so unless you routinely pickpocket children, it won't matter much at all in the end.
LItemFoodInnCommon [LVLI:00098E5F], LItemFoodInnCommon10 [LVLI:0010E0E1] and LItemIngredientFoodPrepared [LVLI:00087135] Conflict between CACO and USSEP: the USKP Meat Pie should be added to CACO's version of the list, otherwise it won't ever be found in Innkeepers' or Food Vendors' inventory.
This is covered by the USSEP - CACO patch from kryptopyr's patch hub, in a different way, but the end result in-game is the same.
RecipeArmorGildedElvenCuirass [COBJ:000DCA0A], TemperArmorGildedElvenBoots [COBJ:000EB789] and other TemperArmorGildedElven[...] Conflict between CCOR and AMB CA: AMB CA should win and CCOR should be ignored. You could let CCOR win the crafting recipe, but then it would be inconsistent with the other Elven Gilded recipes added by AMB CA. Also even though CCOR changes temper recipes these recipes produce nothing in vanilla or CCOR because the corresponding armor pieces don't exist. Regardless, it would make no sense to merge them (this is true in general for COBJ records).
Since AMB CA should be sorted after CCOR, there is really no patching necessary here.
LItemBlacksmithArrows75 [LVLI:0009BC2F] and LItemWeaponBowBlacksmith [LVLI:0009BC3F] Conflict between WACCF and AMB CA: WACCF additions should be kept and forwarded to AMB CA's version of the list, otherwise crossbow and bolts won't ever be found in Blacksmiths' inventory (even if the crossbow integration option is enabled in CCOR).
This looks like a bug to me again. Might be a consequence of the recent leveled list shuffle in WACCF/CCOR/AMB and the decoupling of AMB from CCOR.
DLC2LItemEnchArmorLightHelmet [LVLI:0402BBFE], DLC2LItemEnchArmorLightHelmetSpecial [LVLI:0402BC2B] and DLC2LItemEnchArmorLightHelmetNoDragon [LVLI:0403750B] Conflict between WACCF and AMB CA: AMB CA removes the sublists added by WACCF and replaces them by its own sublists containing "Morrowind-flavored" versions of the enchanted glass helmets, to be found specifically in loot on Solstheim. You could merge the additions from both if you wanted (although it's not the result intended by AMB CA), it wouldn't break anything: both sublists have the same quantity and level, so it would just mean you could still find plain Skyrim enchanted glass helmets on Solstheim.
As you can see the conflicts are few and relatively minor. Even if the conflicting leveled lists were incorrectly patched, this would make no difference in the quantity of loot found. Only the type of loot encountered, or never encountered as the case may be.
So I'm not sure where the perceived difference in quantity of loot is coming from. Furthermore I don't understand why you stopped using patches. Typically the patches from kryptopyr patch hub are quite good and necessary to patch weapon/armor mods that are not WACCF-dependent or WACCF-compatible. Even mods that claim to be WACCF-compatible manage to mess things up in some way or other. You don't have to keep the patches in your load order: you can simply use them as "blueprints" while incorporating their changes into your manual patch, then remove them.
You can ask about specific conflicts or mods you're using, if you want, so we can take a look at what might be going on.
Lastly as regards to Bashed Patches and WACCF:
WACCF comes with a special plugin WACCF_BashedPatchLvlListFix.esp that is intended to correct WryeBash's mistakes processing leveled lists edited by WACCF (see Installation section on the WACCF mod page for usage details). I don't use WryeBash so I can't speak to the effectiveness of this special plugin, but I suppose it may be adequate. I wonder what happens when adding AMB Content Addon into the mix though, for example, since AMB CA is intended to override some WACCF changes, or when adding other mods into the mix, for that matter.

Your question and example are contradictory: if AE is prescribed, it means it's required. If it's required, it cannot be unnecessary.
Please do not piggyback an existing topic with unrelated questions/issues. This topic is about changing a master, but you want to remove a master.
Search this forum or the internet at large for related discussions and possible answers. For example: Remove Masters from a Plugin. Or create a new topic describing your specific problem/question in details if you can't find answers.
Thanks.

Yes.
In this case you'll use "copy as new record (spawn rate plugin)". But if you do that and simply remove the female flag on the copy you'll end up with male vampires with the appearance and voice of females. So it's a little more complicated than that. You need to keep the stats and equipment but change the voice and appearance (head, hair, etc.) and possibly outfit to a male version. You then need to generate facegen data for these new NPCs otherwise they'll have a black face.
You may also need to make a male version of the NPC template's template (e.g. EncVampire01Template for EncVampire01) to cover all the bases.
You can just add the male entries to the levelled list rather than replacing existing ones. If there are as many female entries as males, you should have a 50/50 chance on average to spawn either sex.
What would be the purpose?

Yes, they are quite confusing.
Start by writing the conditions where the player is immune:
(Wearing Helmet OR Wearing Hat) AND (Wearing Cuirass OR Wearing Robes) Then negate them to get the conditions where the magic effect applies:
(NOT Wearing Helmet AND NOT Wearing Hat) OR (NOT Wearing Cuirass AND NOT Wearing Robes) The above can't be transcribed directly into Skyrim conditions, because OR has precedence over AND, it would be evaluated as:
NOT Wearing Helmet AND (NOT Wearing Hat OR NOT Wearing Cuirass) AND NOT Wearing Robes Which is incorrect.
You need to rewrite the conditions so that they evaluate OR with the correct precedence:
(NOT Wearing Helmet OR NOT Wearing Cuirass) AND (NOT Wearing Hat OR NOT Wearing Cuirass) AND (NOT Wearing Helmet OR NOT Wearing Robes) AND (NOT Wearing Hat OR NOT Wearing Robes) See OR and Complex Conditions on the CK wiki for more info.

Slightly better and safer version which skips Initially Disabled references if they already have an Enable Parent:

As discussed above, the script doesn't check if the reference might be used any other way by the plugin, which would require cross-referencing the reference in the plugin. I'm not willing to spend more than 10 minutes on this, so this is the best you'll get.

errno 24 means "too many open files"
Try setting MaxStdio in EngineFixes.toml to 4096 (or higher if that's still not high enough, 8192 maximum).

It is possible to disable the hotkey for Skyrim's built-in screenshot feature, but it's a "delicate" procedure. You've been warned. Don't blame me if you eff up your control bindings. See WARNINGS and NOTES at the end.
Extract the file interface/controls/pc/controlmap.txt from Skyrim - Interface.bsa located in the game data folder. Install the copy of the file you extracted previously in your mod manager, under the same interface/controls/pc directory structure. Edit controlmap.txt with a text editor. Search for the line beginning with the word 'Screenshot', it should look like this: Screenshot 0xb7 0xff 0xff 0 0 0 Change the second word from 0xb7 to 0xff: Screenshot 0xff 0xff 0xff 0 0 0 You can add comments if you like so you can see the changes you've made: // Original: Screenshot 0xb7 0xff 0xff 0 0 0 // Disabled Screenshot 0xff 0xff 0xff 0 0 0 Save controlmap.txt. Launch Skyrim. Load a save or start a new game. Go to the System/Pause menu > Controls and press the key to reset to defaults (for me it's the T key, yours may be different), indicated by the green arrow in this screenshot:
Exit the menu. WARNINGS & NOTES
You need to use a BSA archive extraction tool to extract files from Skyrim - Interface.bsa. An alternative to using the System > Controls menu to reload the default configuration is to delete the file ControlMap_Custom.txt from the game directory, while the game isn't running. Resetting to defaults means you will lose any change you made to the control bindings. Memorize them beforehand and re-apply them afterwards with the Controls configuration UI. The same procedure can be used to disable or remap other keys. For instance, I use it to disable Quick-Save and Quick-Load, freeing up more Fn keys for use by mods, or to remap Map menu keys, which is not possible via the Controls configuration UI.

Your interpretation of that xEdit script is mostly correct, but you're confusing the count of things with their values. And despite acknowledging DY's distinction between records and FormIDs, you're still apparently confusing between them.
No, that's not right. The script checks these conditions:
The number of FormIDs must be lower than 2048. The value of all FormIDs must be lower than 4096. If condition #1 is met, but not #2, the plugin can still be light by compacting the FormIDs (that is changing their values to be less than 4096).
There is an important piece of code at the beginning, which you noticed and commented on:
if not IsMaster(e) then Continue; This skips over any record that is not a FormID, and only continues processing records that are FormIDs.
To summarize, a light plugin is a plugin with fewer than 2048 FormIDs, each FormID being in the range 2048 to 4095 (FExx x800 to FExx xFFF).

I think so too. There are no icebergs in Riften, or in the Rift, as far as I know  Could be a combination of this mesh + another mod (+ ENB) (+ DynDOLOD).
OP should load whole load order in xEdit and look at all the references of 000A98F8 <IcebergSmall02> and 000180E5 <IcebergSmall02_HeavySN>. See if there are any added by mods. In vanilla, there are 98, and 54 references, respectively.

How are you starting the game to run the precaching? Are you using the 'Precache Grass' plugin in MO2? MO2 > Tools > Tools Plugins > Precache Grass?
How are you 'manually closing' the game?
It's possible the game is crashing always at the same spot during the precaching and not making any more progress. If you're using the MO2 plugin, this will cause an infinite run/crash loop until you abort the precaching, by using the 'Abort' button in the dialog box that appears after the crash and before the MO2 plugin automatically restarts it. You have 8 seconds to click on the button.
If you're not familiar with the whole grass precaching process, do it at least once with a vanilla-like load order. Disable your town overhauls and new worldspaces mods like Gray Cowl and Projet AHO. Run the precaching to successful completion. Observe how it works, open the console while it runs in-game to watch its progress. Notice the *.cgid files it creates in MO2's overwrite folder. Notice the PrecacheGrass.txt file in the game's folder, you can look at its contents to track progress. Notice how the game may crash from time to time and the MO2 precaching plugin automatically restarts it, giving you an option to abort during 8 seconds.
To completely stop precaching and return the game to normal operation, remove the PrecacheGrass.txt file from the game's folder. Do this only if the precaching is stuck, or was interrupted previously and you want to restart from scratch. Otherwise leave it alone and let it finish properly - NGIO removes it automatically upon successful precaching completion.
Look at .Net Script Framework crash logs to troubleshoot repeating crashes that prevent any progress.

It's telling you exactly in the message which SKSE plugin failed: EngineFixes.dll. So, look for the correct version of SSE Engine Fixes.

Looks like you're running Windows 32-bit. BethINI.exe requires Windows 64-bit, which you should be using since your CPU is 64-bit.

It's fine. MO2 tries to be helpful but can be a bit dumb in some cases. It uses a hard-coded list of folder names (meshes, scripts, textures, ...) to determine if a folder contains a valid mod. 'grass' is not among them.
Either of these solutions will get rid of the error:
Create a 'textures' folder inside your 'grass cache' mod folder. Leave it empty, doesn't matter. Right-click on your 'grass cache' mod and select 'Ignore missing data'.

First crash occurred while loading SexLabTools.bsa.
Second crash occurred while saving the game to Save2_328F920D_0_507269736F6E6572_WhiterunBanneredMare_000009_20220130144214_1_1. The log shows:
Possible relevant objects (2) { [ 144] TESNPC(Name: `Miraak`, FormId: 040200D9, File: `Dragonborn.esm`) [ 144] Character(FormId: FF00124F, BaseForm: TESNPC(Name: `Miraak`, FormId: 040200D9, File: `Dragonborn.esm`)) } This is just a hint. It doesn't necessarily mean this particular object is faulty. But if you have a mod that modifies this NPC you can start looking there.
Don't assume people know intrinsically what you're talking about. Please make an effort to provide some context. You're using ASLAL, and you started a new game, yes?
In any case, this has nothing to do with Actor Limit Fix or Bug Fixes SSE.