I still think it’s possible, just not in the way you were envisioning, particularly with editor integration.
To take your example, you don’t need to interrogate the module to return whether or not it can fire. You can store simple variables on the shell class, such as “CanFire,” and modules can be prompted to reach back in and change that variable by event.
When your shell attempts to fire, it interrogates its own CanFire bool. If true, it fires and broadcasts to any module that is concerned with ammo and whatnot. (No iterating, just using delegates.) Said modules do their functional voodoo, and set the shell’s CanFire accordingly. A module can also do the firing at that point, with any kind of additional condition and behavior changes you want.
If you really REALLY want extensibility and interconnection between the modules, you can use a tagging system. Module A is attached, adds Tags X and Y to shell. Module B changes its behavior based on tags X and Y on shell.