I may have been a bit overzealous with assert(fPruneMode != PruneMode::UNKNOWN.

fHavePruned is unknown during ParameterInteraction methods, because it is loaded from block index db, the location of which could be set by a parameter. It might be more elegant to split the ParameterInteraction methods into before and after databases have been loaded. That might also help to avoid various remaining instances of gArgs.GetArg("-prune".

I'm not entirely sure about this. Guessing values for options according to context has the drawback that the system becomes less transparent, harder to troubleshoot.

Also it's good to avoid IsArgSet as much as possible as it's not possible to re-set an argument back to unset state, even by clearing it.

It also seems a large code change for what feels like a small argument handling change.

And if we do this, should we do the same for txindex?

@Sjors: can you elaborate a little bit the use case this solves?

Agree with @laanwj that other arguments would have the same problem (if we would agree it is a problem).
It seems that this adds unnecessary complexity.
I think the current behaviour of refusing to run pruned blockchains where prune= is not set is correct.

The problem I'm trying to solve here is being able to set prune= in QT (#13043) without causing errors if the user later launches bitcoind, or if the user resets their QT settings (at which point they'd get locked out).

Another approach could be to reinterpret prune=0 to mean "you can't prune now, but it's OK if things were pruned in the past (fHavePruned=true)".

A similar problem exists for txindex, but that's solved by #13033, which no longer wipes the transaction index if you launch with txindex=0.

Needs rebase if still relevant

Rebased.

I might make a separate PR with a different approach:

1. interpret prune=0 as not allowing manual pruning, but not failing if chain is already pruned
2. if -txindex or -rescan are set, check if chain was actually pruned and fail if so

I don't think that approach would require much less code, but it is perhaps more future proof, once txindex and rescan work (better) with pruned nodes.

Needs rebase due to merge of #13341

Rebased

Closing this because the rw_config approach in #11082 seems to have sufficient support.