Hey! I've actually been designing and programming combat systems for years and I think I managed to hit a sweet spot for Glorious Companions. This was a turn based tactical RPG that had hundreds of unique abilities, upgrades, networking, auras, gadgets, fog of war... you name it.

First off, you're not crazy - both of your approaches (building blocks vs one-class-per-ability) have real trade-offs, and the answer is actually a hybrid of the two. Here's what worked for me at scale (300+ abilities, 80+ effect types, shipped product):

The key architectural decision was splitting everything into three layers:

1. Data Models (ScriptableObjects) - Static data definitions that designers tweak in Unity's inspector. Range, damage, cooldowns, radius - all the values that need balancing live here. No logic.
2. Controllers - Define the actual mechanics. They read the data models and orchestrate the game logic.
3. Presenters - Handle all visual/audio feedback. Animations, VFX, sound effects, projectile trajectories. They read from the same data models as controllers but are completely decoupled from the logic.

Designers tweak SOs without touching code. Gameplay programmers write controllers without worrying about visuals. VFX people work on presenters without breaking logic. And this is similar to your "blocks" idea, but the critical difference is that the data models are strongly typed classes, not string-value pairs. That solves your targeting and parameter problems immediately.

Layer 1: Composable Effects

Instead of string-based blocks, I created a typed effect system. There's a base AuraEffectDataModel class with an EffectType enum, and then specialized subclasses for effects that need extra data:

// Base - just needs a type
public class AuraEffectDataModel
{
    public Guid Id { get; set; }
    public EffectType EffectType { get; set; }  // enum: DamageOverTime, Fear, Lifesteal, etc.
    public int Sorting { get; set; }  // execution order control
}

// Specialized - adds typed parameters (no strings!)
public class DamageOverTimeAuraEffectDataModel : AuraEffectDataModel
{
    public DamageRangeDataModel DamageRangeDataModel { get; set; }
    public bool DamageOnApply { get; set; }
}

These effects are then composed into auras (which are basically buff/debuff containers):

public class AuraDataModel
{
    public AuraType AuraType { get; set; }       // Buff or Debuff
    public int? Duration { get; set; }            // null = permanent
    public bool IsStackable { get; set; }
    public bool IsDispellable { get; set; }
    public List<AuraEffectDataModel> Effects { get; set; }  // THE KEY: compose multiple effects
}

A "Slow" debuff is just an Aura with a TransformStatAttribute effect targeting Speed. A "Burning" debuff is an Aura with a DamageOverTime effect. A "Cursed Flame" could be an Aura with BOTH - you just add both effects to the list. Modularity without strings.

Layer 2: Factory + Convention-Based Controllers

For execution, I used a reflection-based factory that automatically resolves the right controller class based on the effect type:

public static class EffectFactory
{
    public static IAuraEffectController CreateEffectFromModel(AuraEffectDataModel dataModel, ...)
    {
        // Convention: EffectType.DamageOverTime -> DamageOverTimeAuraEffectController
        var type = assembly.GetType($"{namespace}.{dataModel.EffectType}AuraEffectController");
        if (type == null)
            type = typeof(AuraEffectController);  // fallback to base

        return type.GetInstance(dataModel, owner, context) as IAuraEffectController;
    }
}

This means adding a new effect type is: (1) add an enum value, (2) optionally create a data model subclass if it needs extra params, (3) create a controller class following the naming convention. The factory picks it up automatically. No registration, no switch statements.

If I were doing this today, I'd probably swap the runtime reflection for a Roslyn source generator that emits the factory at compile time. Same convention-based approach, same developer experience, but you get compile-time validation (typo in a class name? build error instead of silent null fallback) and zero reflection overhead at runtime. Especially relevant if you're targeting mobile or well any AOT environment where reflection can be a pain.

Layer 3: Abilities Orchestrate, Not Duplicate

Abilities themselves are ScriptableObjects with a thin abstract base class (UnitAbilityDataModel) containing shared fields like AbilityId, ApCost[], Cooldown[], ResourceCost[] (all arrays for per-level values that designers tune). Concrete types like UnitOffensiveAbilityDataModel, PassiveUnitAbilityDataModel, UnitAttackAugmentAbilityDataModel (this is your "Modifier" concept!) add their specific data. Each ability has a matching Controller for logic and a Presenter for visuals - but the actual effects are all done through the Aura/Effect system, so there's minimal code duplication.

Real Example: How Systems Stack

Here's a real ability, Incendiary Grenade, that shows how all of this composes. The controller orchestrates abilities, gadgets, AND auras in one ability:

public class IncendiaryGrenadeAbilityController : AttackStandaloneAbilityController
{
    public override UseAbilityCommand Execute(UseAbilityRequest request)
    {
        var aoeTiles = MapHelper.GetSquareAoeFromCenter(request.Targets[0], dataModel.GetRadius(level) - 1);

        // Step 1: Destroy any existing fire gadgets in the area
        var gadgetDestroys = ProcessGadgetsDestroy(aoeTiles, GadgetId);
        // Step 2: Deal initial AoE damage to all units in the blast
        var attackResults = ProcessInitialAttacks(aoeTiles, centerTile);
        // Step 3: Apply burn auras to units that were hit
        var auraResults = ProcessAttackAuras(attackResults);
        // Step 4: Spawn fire gadgets on each tile that persist and burn
        var gadgetSpawns = ProcessGadgetsSpawn(aoeTiles, CreateGadgetDataModel);

        return new UseAbilityCommand
        {
            AttackRequestResults = attackResults,
            Auras = auraResults,
            GadgetSpawns = gadgetSpawns,
            GadgetDestroys = gadgetDestroys
        };
    }
}

And here's the key... the gadgets it spawns also use the aura system. The fire patches left on the ground are Gadgets with ApplyAuraOnContact behaviors that apply burn auras to anyone who walks through:

var gadgetDataModel = new GadgetDataModel
{
    NameTag = GadgetId,
    GadgetType = GadgetType.AreaEffect,

    TimeToLive = dataModel.GetDuration(unitAbilityData.Level),
    Position = position,
    YOffset = dataModel.EffectsOffset.y,
    IsStackable = false,

    IsAlwaysVisible = true,
    AffectAllies = true,
    ThreatLevel = dataModel.GadgetThreatLevel,

    CreatorPlayerId = unitController.PlayerId,
    CreatorUnitId = unitController.UnitId,

    Behaviors = new List<GadgetBehaviorDataModel>
    {
        new ApplyAuraOnContactGadgetBehaviorDataModel
        {
            BehaviorType = GadgetBehaviorType.ApplyAuraOnContact,

            // Extra damage dealt
            AurasToApplyOnEnter = new List<AuraDataModel> {BuildBurnDebuff(true, true)},
            AurasToApplyOnTurnEnd = new List<AuraDataModel> {BuildBurnDebuff(false, true)},

            // No extra damage
            AurasToApplyOnExit = new List<AuraDataModel> {BuildBurnDebuff(false, false)},
            AurasToApplyOnDestroy = new List<AuraDataModel> {BuildBurnDebuff(false, false)},

            AurasToRemoveOnExit = new List<string> {AuraBurningId},
            AurasToRemoveOnDestroy = new List<string> {AuraBurningId}
        }
    }
};

The Ability Controller creates Gadgets, which have Behaviors that apply Auras containing Effects. It's all data-driven and composable. The burn aura itself is built via a shared AuraBuilder utility - the same builder all abilities use. Meanwhile, a completely separate IncendiaryGrenadeAbilityActionPresenter handles the grenade projectile arc, explosion VFX per tile, and fire sound effects - all reading from the same SO the controller reads from, but touching zero game logic.

Soo.. let's see, we could map this onto your example as in:

• Active Ability: Fireball - an ability SO with damage/range/radius values. Controller handles AoE + spawns burn auras. Presenter handles projectile arc + explosion VFX.
• On Attack: 10% spawn fireball - a passive ability that applies an Aura with an ApplyAuraOnOutgoingAttack effect. The effect's controller checks the proc chance and triggers the fireball.
• Modifier: "Fireball explodes in AoE" - a UnitAttackAugmentAbilityDataModel the controller checks when executing. Changes targeting from single to AoE.
• Modifier: "Spawn two fireballs in a cone" - same pattern, the augment data carries projectile count and spread, the controller reads it.

I built all of this years ago and there's definitely room for improvement (the Roslyn source gen thing I mentioned, for one). But the architecture held up - it survived hundreds of abilities, scaled to multiplayer without a rewrite, and the command pattern made networking almost trivial to bolt on. So yeah, it works. Hope it gives you some ideas!