GJS, etc., Panels For Easier Iteration?
Current problems
There is a substantial backlog of feature requests in the GNOME Settings Issue Tracker. More niche integrations in particular remain (understandably) a low priority for GNOME Settings' existing pool of developers.
Currently, panels in GNOME Settings appear to all be written in C. However, compared to Gtk's other language bindings, Gtk's native C is more difficult and complicate to use, due to, among other things, relatively complex manual memory management, even with all of GLib's amenities.
The fact that GNOME Settings panels are written in and apparently must be written in C probably contributes to the backlog of unresolved issues.
Goals & use cases
For example, one open feature request is direct support for Logitech Unifying Receivers. However, the existing library for this purpose, Solaar, is written with PyGObject, and porting its code and functionality from Python to C would be non-trivial. If individual GNOME Settings panels could use different Gtk language bindings (or even multiple bindings, though idk how that would work), a developer familiar with PyGObject could much more easily integrate Solaar's functionality into GNOME Settings.
As a different example, the GNOME Shell is increasingly written in GJS, rather than C. Allowing and gradually porting GNOME Settings panels to GJS could allow easier code sharing and collaboration between GNOME Shell and GNOME Settings developers.
Finally, allowing more rapid iteration could help the developers of GNOME Settings make the application more adaptive to mobile and touchscreen layouts.
Requirements
Specifically, allowing GNOME Settings panels to be written using Gtk bindings in languages without complex memory management should serve the purpose of allowing a larger pool of developers to develop and maintain GNOME Settings panels and more quickly work through the existing backlog of Issues.
Relevant art
Probably the biggest example/comparison here is with the GNOME Shell, a core part of the GNOME Desktop which (as I understand it) is almost entirely GJS rather than C at this point.
Proposal & plan
Creating a framework in which individual panels could be ported to GJS (and possibly also PyGObject and others) would create a more feasible path than, say, porting the entire application to GJS all at once (if that is even a desirable thing to do).