Blackbird Wanderer

Do you mean you accidentally released a subjugated Captive? If yes, then yes, this is normal and deliberately designed that way. There will eventually be a different set of after-effects associated with this occurrence as compared to a pre-subjugation release.

SL is extremely intertwined and that would be a daunting task indeed, but I wouldn't say it's impossible. Undesirable, but not impossible. Why? The mod as it is right now is just the tip of the iceberg. As the plot develops it will paint the picture of the source of the restraints, the shadowy figure(s) behind them, and their eventual goals.

See post above or the OP.

Great point! Indeed; you need not do anything at all for those cases. It does not do the redirect blind; a script still searches in the load order for the filename presented by the JSON similar to the file search from the old versions of SBC. If the mod doesn't find the filename in the load order, it concludes it's not used and marks its variable such. Blanking the field for an unused mod, while unnecessary, would have no additional effect. (See the last two pics on the OP for how this gets presented in the MCM. )

Yes, this exactly. Here's my test example with DFT Bandit Camps, Genesis Watchtowers Reborn, EtR-MBC, and MBC packed into a merge called "Bandit Camp Merge.esp". The JSON is already created (the example above) and is just edited in Notepad or the editor of your choice. Easy. Until edited, the file represents the default filenames of the optional mods. All you're telling the system is "look for this instead" with a new name.

For those interested (the 255 mods crowd especially), I've now developed that previously discussed idea about detecting optional mods (like MBC and the other bandit camp mods) when they are merged into a consolidated file, though I did it via a completely different method than originally conceived and it should be more user friendly as well. The file names used for this check are now written to a Json file where the user can edit each line to change the filename for each corresponding mod.

Slick. This, combined with your Player defined JSON import idea, seems to scratch the itch.

This seems like a tough nut to crack; however, since we're restricting the examination to the Player and not scanning all over the place makes it somewhat easier since the Actor in question is fixed. It's somewhat baffling there appear to be, to the extent of my knowledge and quick research on it, no Papyrus Functions that will return the number of active effects present on an Actor like there are with number of items in inventory, etc. That's the missing link that makes this idea untenable directly via Papyrus under the stated restrictions. There are Fuctions in Papyrus that answer the question, "Is this effect present", when you ask about a specific known effect -- but that violates the premise of not pre-building something into SLD. I think the idea is still possible, but not without predefining some Properties in SLD first or with a patch to it. There's the rub. As such, the JSON idea @Lupine00 mentioned probably has the most merit, and the highest yield to effort ratio.

@Blackbird Wanderer is the smartest person I know about that stuff, if they don't know, I wouldn't even begin to know who else to even ask. Need more info / better problem description. What active effects are we talking about and on whom?

Ah! I didn't understand the itch we were trying to scratch. Now I get it. A while back I had thoughts of using a solution like how EFF does things by dropping an invisible marker that is assigned to only that Actor. Not unlike what @shardoom suggested, but dynamic instead of pre-positioned. I think that would do it. Since I don't really play other than play-testing, I won't see some problems or think of things like this unless helpful users like you suggest them, so thank you!

I'm perhaps not understanding what you've described, particularly the "remember where they chose to go" part. If you (or an expert) successfully remove their restraints, they generate a (random) destination that deliberately probably has nothing to do with their original backstory. New direction / starting over, etc. Once they are equipped, you send them on their way and they go there. If you are the Thane of Whiterun (other cities to follow) you can suggest a destination with varying degrees of success depending on their backstory, your Speechcraft, and what you suggest. e.g., Former Bandits are reluctant to join the guard, but are persuadable. Once they arrive at their destination they sandbox there and become available as a follower and marriageable (unless you've suggested they join the guard). What exactly are you looking for?

I worked on this a bit and developed a way to halt the script from beginning if another instance of the script is already running so this should eliminate the scanner overdrive you described. While you got me thinking about it, I also started to work on a filtering mechanism to not scan in certain circumstances such as in towns, cities, and dwellings. It's a low demand thing, but any little bit to lessen the processor load helps, especially on low end machines.

I believe these are related issues and there may be parallel instances of the script running simultaneously. The script running again may be appropriating the Aliases the Actors were filling for a subsequent scene before the first scene even initiates. I may need to build in something to ensure a single pass completes before another initiates. Thanks for the report.

Curious. Sort of like something trying to initialize with activation is being interrupted? I'll keep an eye out for what that could be as I reinvent that script.

Indeed, it is. I don't know that I fixed the issue since I don't recall ever seeing it before, but now is a perfect time to poke into things that have not been examined in a while.