Unfortunately I have never done coding and the 397 lines of code are way over my head. I don't have time to look into this now, maybe sometime in the future.
This is a huge problem that some of the developers and code writers of HG/PiX10 need to deal with. You wouldn't say, "If you can't code you shouldn't use HG." It's a ridiculous statement that will turn future users off to the product. In fact, the average HA user can't bear the thought of stumbling through github.
Most of us are not coders, we don't want to be, we don't have the time, we are better racecar drivers than coders, any number of reasons. That's what macros, events, routines, etc are for. That's why there are automatic transmissions, because some people just can't deal with or don't want to deal with shifting gears, clutches, etc. Imagine how that would be with today's ten speed automatics. They don't make ten speed manuals that require another leg to operate. The technology for transmissions went where the users wanted it to go, not the manufacturers. The manufacturers simply developed what they sold more of and what their competitors sold more of.
The "users" of HA don't want to spend an inordinate amount of time just to get light A1 to come on 30 minutes before sunset, adjust automatically for DST, brighten when someone rings the doorbell, then return to where it was after a few minutes. Never mind not shutting off at dawn if it's totally overcast.
Tuicemen is right. Flags are coming to HG because the users want it. The same will go for many other things as long as ease of operation is kept front and center. Flags are really there already at least for me as virtual devices, which is what I'm used to. Call it what you want, it's another option and the end user will pick the method that's most convenient for them. It might be one obfuscated line, or a well designed method of getting to the desired operation of your particular device.