I also wonder how that would interact with something like the 'Extreme Modifications' hull mod from the 'Ship/Weapon Pack'.
Would it be in the same way?
ie: Raise the base amount of mods the specific ship could have.
SWP isn’t up to date for 0.95 so I can’t say for sure, but iirc what it did was cost a negative amount of OP and had a negative effect. If you built it in, it would cost 0 OP and you’d just be left with the negative effect. I don’t think this is an issue with either this mod or just S-mods in general — rather, extreme modifications would have to be updated to either give an additional benefit when built in, or just make it unable to be built in (but this mod ignores no_build_in by default, so in that case it would be up to the user to realize that building in a negative-cost hull mod is detrimental).
Edit: Ok, I see that SWP has a pre-release version and extreme modifications now grants an additional S-mod instead of costing negative OP. Results from testing: poor compatibility. Extreme modifications becomes permanent as soon as it's applied. It does work in that it gives you the additional S-mod slot, but yeah, the fact that it immediately becomes permanent upon clicking on it isn't desirable behavior. Also, if you try building it in via this mod's interface, it will disable itself and won't be able to be built in, saying that it "can't stack with itself."
The first issue (immediately becoming permanent) is probably because SWP is using Misc.MAX_PERMA_MODS rather than, say, Global.getSettings().getInt("maxPermanentHullmods"). Since this mod sets Misc.MAX_PERMA_MODS to -999, that would definitely cause SWP to think that every ship is always at its S-mod limit. I'd have to do a considerable amount of work to make this compatible -- first, I'd have to change how I disable building in hull mods with SP, for example by adding no_build_in to every hull mod and really_no_build_in to hull mods that already had no_build_in. Next, I'd have to actually change a fleet member's Stats.MAX_PERMANENT_HULLMODS_MOD when the increase-limit option is chosen, otherwise SWP wouldn't be able to see the real number of S-mods able to be built in. I'll think about doing this... maybe when SWP gets its full release or if people start complaining about funky behavior.
The second issue (immediately disabling itself when trying to build it in after overriding no_build_in) I would say is a problem with SWP's implementation of extreme modifications. Stacking a hull mod with itself doesn't make sense (since when was this possible?), and hull mods should always be compatible with themselves. For example, this is in the code for shield shunt:
public boolean isApplicableToShip(ShipAPI ship) {
...
if (ship.getVariant().hasHullMod("shield_shunt")) return true;
...
}