[Xposed Framework Modules] trjlive:
Several of these requests are already included with GravityBox. I've outlined below (numbers correspond to your original post).

3.) Center clock is already available in the Status Bar --> Clock settings.

8.) If I recall, the developer stated he had tried blue on lockscreen, but it's not an easy thing because of the way Android renders the lock screen. It would take a tremendous amount of effort for such a small effect, therefore it was decided not to pursue this feature.

9.) While some devices support charging LED built-in, the hardware of the Nexus devices do not. Any app that emulates this functionality is therefore doing so in software, which means that it holds your device awake all the time, so it can monitor for charger connected. This can become a major power waster, so and GravityBox would have to implement it the same way, essentially causing significant wakelocks while charging.

12.) You can change the color of the data activity arrows with any hex color code or use the built-in color picker. Status Bar --> Signal Cluster Settings --> Data Activity Color --> choose color or type in color code in #000000 format.

Some of these requests are nice, although I will mention many of them have been brought up before. Some have been implemented over time, and others have been determined to be too difficult to be worth the time to implement.

The developer basically has to make a determination about the "return-on-investment" for each feature request. Just because something is "technically possible", doesn't mean it's "feasibly possible". It might take 100 hours or more to develop a new feature that less than 1% of users would actually use, therefore the ROI is extremely low. That's just an example of how some features, while possible, are decided not to be included in GravityBox.

Also, there's a "Feature Request" tab at the top of this DevDB project, in the black bar above all the posts, that the developer likes to have feature requests added to. That way, he and everyone else can track the progress of potential feature additions. :good:

Hope this helps! Thanks for the great feature suggestions! :)

---------- Post added at 01:44 PM ---------- Previous post was at 01:30 PM ----------

I'm not sure GravityBox would have any way to know whether the Hangouts notification was SMS or not. While Hangouts might separate out the notifications internally, it still delivers them to the notification framework in the same way. Therefore, GB would just see the notification coming from Hangouts.

GB wouldn't know if it was SMS or Hangouts convo. GB can only act on the notification in the way it is presented to the Android notification framework. If that notification is being presented to the framework from Hangouts in the same way whether it's SMS or Hangouts convo, I really don't think that GB would be able to determine the actual origin of the alert beyond that it's coming from Hangouts.

You can create filters in GB UNC to only alert on certain keywords, so you could add your SMS contact names into it, so GB only alerts if it sees one of those names in the notification. But if you use the same name in a Hangouts convo, GB will also alert on that notification. Unless there's some other method that could be used to determine Hangouts notification origin, I just don't see how this would be feasible.