Ideally, these rotating warning lights should consume ElectricCharge while active, and if ElectricCharge has been depleted, should automatically shut down.

EC consumption works (mostly), with one small issue - if the vessel's batteries run dry, the lights will continue to flash and cannot be switched off.

Will continue to investigate.

RoverDude (@BobPalmer) pointed out that the stock ISRU is an example of a part with resource consumption and looping animation.

I've pushed a rudimentary implementation for the white strobe, but based on feedback by beta testers Bomoo and diomedea, none of the strobes are running (the white one is, in fact, no longer toggleable).

Will need to investigate.

nli2work provided the ultimate working solution, which concurrently offers a better way to handle #1 as well:

• In Unity, create two instances of the spinning rotor
• Rotor A is animated to loop forever, regardless of the strobe's on/off state
• Rotor B is does not rotate
• An animation applied to the parent of Rotors A & B "switches" between the two meshes by scaling up one Rotor and shrinking the other. In other words, in the "on" state, the Rotor A is full sized, while Rotor B is scaled down to 0.1% and is effectively hidden; the situation is reversed in the "off" state)
• The toggling animation also controls the LED emissives and light transforms
• ModuleLight is then used to toggle the Strobe on and off
• Due to animation layer support in KSP 1.0.5 onwards, this allows the toggling between rotors to be combined with Rotor A's inherent spinning

The Amber Strobe-O-Matic was modified as per the procedure outlined above, and tested successfully in KSP 1.1 prerelease - the strobe is automatically added to the Lights Action Group, ElectricCharge is consumed while the strobe is active, and the strobe shuts off automatically once it runs out of EC.

Much easier and more robust than futzing around with bizarre part modules or being reliant on a third-party plugin!