I guess in the end it comes down to whether charge limits should be viewed as a system-level setting (with privileged access, system-wide config) or a user-level setting (without requiring privileges, user-specific KConfig).
On my laptop system, which does persist charge threshold values via firmware, changing the thresholds in my dev user account will also change the thresholds for my stable Plasma 5.27 user account, or even an unaware GNOME session on the side. That fact by itself makes me more comfortable about clearly labeling it as a system-wide settings requiring root privileges. On the other hand, perhaps systems like mine will die out and we shouldn't lock ourselves into the old ways of setting thresholds going forward.
Regular session switching with different settings may or may not affect the longevity of the non-volatile memory that the firmware relies on. @broulik left a comment to that effect in chargethresholdhelper, this may well be a reason for requiring privileged access.
What we'd get with this approach vs. !253 is a similar behavior for my kind of laptop as well as all the newer ones that don't persist thresholds across reboots. And no unintentional non-volatile memory churn. Absent those two arguments, I wouldn't care much about retaining the current system-level semantics.
PS: I would prefer the nomenclature
restorechargelimitorrestorechargelimit. It is more inclusive towards MR !248 and potential future implementations.
Apart from the fact that both of those are the same, yeah I think that makes sense. Something else I've got on my mind is what the API will look like once we introduce support for multiple batteries. Perhaps we should reserve the more general name restorechargelimit for a time when it's clear how to deal with different kinds of charge limits more generically.