Concept ACK. Clearly makes sense for some args. (c.f. setmocktime)

Not sure if this should be enabled for all args. (Setting minRelayTxFee may result in unexpected behavior.)

Rough concept ACK.

To speak generally and scope the problem, each setting has been written with the idea that it is largely static throughout program runtime.

At an engineering level, you have to revisit each setting in the context of thread safety, as well as wider impacts such as, e.g. changing min-relay-tx-fee and then running with a mempool temporarily disjoint from that value (or, alternately, adding setting-specific trigger code to be executed when setting A or B is changed at runtime).

tl;dr Good goal, but requires per-setting analysis, and possibly per-setting runtime reconfiguration code.

Concept ACK.
Agree with @jgarzik.

Currently, your new setarg command only protects the variable by cs_main (and cs_wallet). Not sure if that would be sufficient (IMO it wouldn't be sufficient for net limits (-maxuploadtarget)).
Instead of directly accessing globals vars, a setter/getter (could also be global) in the according code region would result in a better, cleaner code (or a class that could handle the global vars).

Conceptual, when supporting a setarg, there should also be something like a getarg (to check/ensure a certain runtime var).

This would be great!

Yes, I intentionally designed this to require explicit opt-in from each setting.

Having a getter/setter for each item would IMO bloat the code and discourage making options configurable instead of making it trivial to do.

If we're replacing settings with classes (is that really low-overhead enough for some settings?), however, that might solve all the concerns at once - it could manage the correct locks only, and refuse assignment after being read (for arguments that's appropriate for).

Concept ACK. I know this could save me from a few restarts here and there :).

Having a getter function too would be helpful.

In JoinMarket sometimes people misconfigure -walletnotify, the getter options would be a way to detect this and display a helpful error message.

This sounds like it could cause havoc in some places, especially where the assumption of constants has been made.

Otherwise, concept ACK.

concept ACK - will the changed values be remembered so that if bitcoind is restarted it will continue with the last-used values?

No, for that we'd need to combine this with #7510.

@luke-jr ah, in that case I'm strongly in favor of #7510 also then - we surely need a way to enable configuration changes to persist between runs, don't we?

As #7510 is too controversial, let's continue with this. Needs rebase.

Dumping memory pool slightly shifted the priority here, because one can easily restart the node, but still looses connections etc. So still concept ACK from me.

@luke-jr, this pull request has had many Concept ACK. I think that it is worth the rebase, and a second look.

Not a priority for me right now.