I’m mostly explaining the reasons for the limitations to try and drive home that this isn’t a matter of preference - if you don’t use the options when they are available, you will eventually wake up to a broken config (like the people affected by this).
Well, that part is trivial…
but this part is completely impractical. How do you propose configuring Firefox policies (that are deliberately locked to full-system paths because they’re intended to do admin-level config) per-user? This is impossible without heavy sandboxing with all its issues, or outright patching Firefox.
User- and system-level configurations are inherently completely different, you need separate implementations for each. Declaring that the API could look similar doesn’t make it possible to implement it that way.
Things like the portable services interface (although I’m still worried about its impact on e.g. sensible sandboxing with systemd, or credential management) do make it feasible for at least the subset of applications where privileges do in fact not matter, to be fair, but those are typically not the ones that already have modules.
users.users.programs already exists on the other hand, if you want to put things in a specific user profile’s $PATH instead of the system-wide one. That option is also currently a list.
Anyway, I’m getting off-topic; I think I’ve linked you to enougn places where you might find more if you want to join the work effort to mold things into what you want 