The problem with incorporating accuracy into sensors and jamming into point defense is that it requires you to research something you may not want or need. So I'd favor separating them out.
I wasn't suggesting tying jamming into point defense. I was suggesting renaming the chaff and ECM technologies, components, and modules in the point defense line to something else and then using chaff and countermeasures and the related component/technology/module names in a jamming line. I don't see any particularly good reason to create an entirely new line for boosting accuracy, however; sensor technology is a natural place for that.
As far as being required to research something you may not want or need, so what? That's the nature of technology in video games; I don't "want" basic lasers from the initial weapons tech when I'm trying to develop missiles for the ships I intend to build, but I get them anyways because they're along the way and I'm not going to get my missiles without researching lasers anyways. Besides which, if the existing sensor line of techs merely had an extra component attached to each tech, then I see no reason at all to complain about being "forced" to get the regular sensors when you pick up the more advanced ones. It's not like I had to research additional useless technologies to get these.
Something I think is not clear to most of the folks in this thread is that all modifiers are additive.
This means that when you put a jamming module on a ship that adds 20% jamming and add another that add 30% jamming you get 50% jamming.
Not entirely. You can use <BonusType>Multiplier</BonusType>, and while the bonuses granted by the component will be additive with one another, they will be multiplicative with some base value; +300% jamming as a multiplicative bonus isn't so powerful if the base jamming level is only 5% or 10% or something like that, though you'll still need something to actually give you that base jamming level (yes, the +300% jamming in the example would be problematic with the existing faction trait that gives jamming, but remember, this is just an example, not a suggestion for actually-attainable values).
There's also the option of creating components that have both flat and multiplicative bonuses to the same statistic to create a (rather poorly implemented) stacking penalty; to take your example of components granting 20% and 30% jamming, I could add a 10% penalty to jamming on each and get them to add up to 40% jamming instead of 50% (granted, doing it that way would result in 18% and 27% jamming as the real value of each component; you could go for a -17% multiplier and use 24% and 36% for the component values to get ~20% and ~30% as the real component value while getting ~40% as the combined total). I don't particularly care for the stacking penalty option as it's going to be rather unclear what the real component effects are, especially if seemingly strange numbers (such as a -17% multiplier with 24% and 36% flat bonuses) are chosen, but it's one possible way of handling stacking issues. And if you really want a "one component of this type" (rather than the "one of this specific component" granted by <OnePerShip>True</OnePerShip>), you could have all components of this type provide twice the flat bonus you want them to give while also carrying a -50% multiplicative bonus of the same effect type; two components add up to -100%, and as far as I know there aren't any multiplicative jamming bonuses in the base game to counteract tha, though this might have some complications for the fleet-wide jamming modules (on the other hand, it's not like it's terribly unrealistic that a ship already producing noise worth 30% jamming wouldn't get the same benefit out of an EW ship spewing out noise worth 25% jamming that a ship not creating its own jamming coverage would get).
An alternative to the above stacking penalty would be to make the components inconvenient to stack due to size; if each jamming component requires 30 capacity and only provides 20% and 30% jamming, stacking both is not going to be particularly appealing until you have a significant hull capacity bonus (and even then it may not be appealing for any but the larger hulls, for which you could compensate by giving larger hulls a multiplicative jamming penalty; spending 60 capacity to get 0.75*(0.3 + 0.2) = 37.5% jamming might not be the best of ideas). Another alternative is to design the components to be stacked; a size-3 component that gives 10% jamming is neither particularly strong nor particularly weak, and if there are 4 of these with unique names you end up with something where the individual components are not terribly weak and so may be worthwhile individually, are practical to stack even on somewhat small ships, and don't stack up to a ridiculously large jamming bonus (assuming you remembered to put <OnePerShip>True</OnePerShip> on each; even so, it'd probably be desirable for there to be a component or set of components to boost accuracy to counter this, as while 40% jamming might not be huge it's not small either).
Therefore you cannot simply add accuracy to sensors as every instance of a sensor added would compound the problem, all ship modifier stats are currently attached to "one per ship" modules with limited availability to prevent bonus stacking to ludicrous degree's.
Or you could be a little less simple and do something like this:
<ShipComponent>
<InternalName>NavigationalSensors</InternalName>
<DisplayName>NavigationalSensors_Name</DisplayName>
<Description>NavigationalSensors_Dec</Description>
<ArtDefine>Sensor_01</ArtDefine>
<Category>Modules</Category>
<Type>Sensor</Type>
<PlacementType>Sensor</PlacementType>
<Stats>
<EffectType>Value</EffectType>
<Target>
<TargetType>Ship</TargetType>
</Target>
<BonusType>Flat</BonusType>
<Value>0.25</Value>
</Stats>
<Stats>
<EffectType>SensorRangeManufacturingCost</EffectType>
<Scope>Queue</Scope>
<Target>
<TargetType>Ship</TargetType>
</Target>
<BonusType>Flat</BonusType>
<Value>13</Value>
</Stats>
<Stats>
<EffectType>SensorRangeMass</EffectType>
<Target>
<TargetType>Ship</TargetType>
</Target>
<BonusType>Flat</BonusType>
<Value>8</Value>
</Stats>
<Stats>
<EffectType>SensorRange</EffectType>
<Target>
<TargetType>Ship</TargetType>
</Target>
<BonusType>Flat</BonusType>
<Value>1</Value>
</Stats>
<Stats>
<EffectType>Accuracy</EffectType>
<Target>
<TargetType>Ship</TargetType>
</Target>
<BonusType>Flat</BonusType>
<Value>0.20</Value>
</Stats>
<Stats>
<EffectType>Accuracy</EffectType>
<Target>
<TargetType>Ship</TargetType>
</Target>
<BonusType>Multiplier</BonusType>
<Value>-.1</Value>
</Stats>
<Stats>
<EffectType>Maintenance</EffectType>
<Target>
<TargetType>Ship</TargetType>
</Target>
<BonusType>Flat</BonusType>
<Value>0.25</Value>
</Stats>
<Prerequ>
<Techs>
<Option>TechTree</Option>
</Techs>
</Prerequ>
</ShipComponent>
The accuracy of the weapons will be ([base accuracy] + sum[flat-typed bonuses])*(1 + sum[multiplier-typed bonuses]), if I'm not mistaken. The above version of a Navigational Sensor would therefore leave a vessel with the following (beam/missile/gun) accuracy for the number of navigational sensor components shown at left.
- 108%, 99%, 90%
- 112%, 104%, 96%
- 112%, 105%, 98%
- 108%, 102%, 96%
- 100%, 95%, 90%
- 88%, 84%, 80%
- 72%, 69%, 66%
- 52%, 50%, 48%
- 28%, 27%, 26%
- 0%, 0%, 0%
If you're at all smart about how you implement things, even putting theoretically-overpowering bonuses on components which are not one-per-ship is not going to be problematic. Lasers, missiles, and guns have base accuracies of 100%, 90%, and 80%; I'd be more inclined to say that the above component with its 20% flat accuracy bonus is too weak than too strong, particularly for the more accurate weapons.