To my knowledge, there are currently 2 issues with IS_OCO packets and lights in general:

• Response timing to IS_OCO packets is erratic at best (sometimes the lights switch almost immediately, sometimes you have to wait much longer, to the point that flashing lights (changing state every 0.5s) may keep the commanded light on or off for more than a full second (likely because it does change state at some point, but immediately reverts because of the new packet)).
  
• We don't have enough working and controllable lights (pit entry/exit, track-side lights (or LED panels for Blackwood).
  

The first issue forces InSim developers to use "backup lights" for custom starts (which isn't too bad in itself, as having GUI/HUD lights is generally a good idea), because the real lights typically change state late and are not reliable for reaction time (I won't get into 5-red-lights style start lights here, although having those on all tracks would be good as well). The issue is easily noticeable when sending a message right after sending the IS_OCO packet.

The second issue, which hopefully is planned to be addressed in the future (the lights are there after all, so we could have them accessible to InSim with index values other than 240, or identifier values for index 240) would really help to make the track more alive (having green lights/LED panels during a safety car period feels wrong, after all, and being able to use the blue lights at pit exit (or a layout object with a blue light) would also help).

Now for the proposed changes:

• If possible, having lights react more quickly to IS_OCO packets would be appreciated, as I don't really understand why they wouldn't be updated as soon as the packets are received. By the way, the issue is only visible with host InSim apps, in local apps, the changes are immediate.
  
• Whether the above can be addressed or not, it would be nice to be able to set lights to a flashing state, so we don't have to repeatedly send on/off IS_OCO packets (a period of 1s (0.5s between state changes)) should work for most scenarios.
  
• Valid index values are currently 149 (with 150 and 151 already reserved for new layout objects) and 240; just like layout objects have 64 identifier values, having some of those for track-side lights seems like a good option for controlling them.
  

As an additional note to that last point, maybe more lights could be added on official tracks; I checked around Westhill, the National configuration has 2 of those, and International has 4. I don't know how those lights are supposed to be placed in real life, but there is no light at all between the point both configurations converge and the main lights at the finish line, I feel there should be at the very least one.