My intuition is that there are different levels of integrations for the services.* subtree. In my mental model, the scale goes roughly like this:
- Trivial
Only an “enable” option, possibly a “configFile” option if applicable, otherwise rely on whatever is in /etc/xxx/config) - Minimal
Some basic options, at least one of extraConfig, or configFile) - Mixed
Several config options covering “most” use cases, the remaining in extraConfig - Complete
The service can be fully configured in Nix options, without relying on an extraConfig argument, think bluethooth) - Advanced
The service is fully configurable in nix, and options are type-checked, and tested with config testers. Currently bluetooth does not prevent the insertion of mis-typed keys. Think knot-config-checked where the check is done with the right version of the package as configured in nixos.
Note that all of these support levels are valid. It just describes how tightly the service is integrated in nixos config system. Often, two styles can coexist. At the moment, bluetooth still supports extraConfig, even if is deprecated.
Beyond that, a usage count would be really interesting, just as it would be for nixpkgs packages, but that seems more difficult to achieve.