NixOS declarative accessibility options vs. GNOME runtime settings: where should per-user screen reader state live?

Integration boundary

NixOS exposes declarative options such as services.xserver.desktopManager.gnome.accessibility.enable and programs.screenreader.enable to start services like Orca and speech-dispatcher at boot. GNOME, however, keeps per-user accessibility toggles in its own runtime store (dconf/gsettings), which Nix does not track.

The unresolved decision

Enabling the system option starts the required services, but the user must still activate individual features through GNOME Settings or gsettings. Home Manager can manage some per-user settings declaratively, yet it does not automatically synchronize with the system-level NixOS options. This creates two competing sources of truth for the same feature, and user-level overrides drift out of the configuration.

Assume a recent NixOS release (23.11 or 24.05, noting option names may differ between them) with GNOME on X11 or Wayland. Verification would involve rebuilding with the option enabled and checking whether Orca actually starts and whether systemctl --user status speech-dispatcher reports active after login.

Questions

• Is there a supported way to declare per-user GNOME accessibility toggles (e.g., Orca on/off) so they survive rebuilds without manual gsettings calls?
• Should system-level options and Home Manager settings be combined for one user, or does that risk conflicting service definitions?
• What is the recommended approach to detect and reconcile drift when a user toggles settings imperatively at runtime?