Signal gantries and snow covered signals, etc. would require either for the GRF file to define additional sprites for those, and for the drawing code to decide which sprites to use when drawing the signal, or for the GRF to be called when drawing a signal using a varaction 2/callback, along with actions 1&3 as eis_os suggested; some or all of the data could be cached in the landscape array (or elsewhere) to minimise the number of GRF calls required. Bits 0-2 in L6 are unused, as is L7 (although it is planned to eventually be used for abandoned rails).
How will overwriteing work? As TTDPatch Base GRF should have the signals and other Signal grfs should be able to overwrite it.
If the feature is turned off, and/or no GRF file is activated which defines the necessary sprites, etc., then just display the ordinary signals using the existing code.
If the feature is turned on, and a GRF file defines the sprites, etc. required, use that method to display the signal.
For the flexibility aspect it should be fairly easy to simply allow the GRf file to specify for each signal: one or more sprites, which can then be stacked on top of each other (or it could be done by coordinate offsets), and which colours in the palette used should be changed for lights.
The GRF file could first specify the light colour for each 'feature', ie. go=green, stop=red, PBS=orange, etc., such that a colour per light type is specified.
Alternatively, it is probably easier if the GRF file is simply passed the bitmap of which features (lights) should be on, the properties of the signal and landscape properties, (using a var 6x/8x ?), and it selects the appropriate sprites and a recolour pseudosprite (or it modifies an existing one via a variable modification action), or someother mechanism of specifying variable colours. Specifying a sprite for each dot seems unnecessary to me, and a pain due to things like offsets, particularly with variable size signals.
I've notived that the signal sprites in ttdpbase.grf use up to 4 similar colours for the light dots, but this should not be a problem as either 4 colours can be modified per light, or it can be changed to just one colour, as in the CSD set lights shown above, (whose lights look the same).
This is only my ideas on feasible possibilities.
Thanks for your feedback and suggestions on this idea.