Just pointing out for anybody else; this is not specific to ssh-ng, which is really good for things I've been playing around with.

IMHO this is not the right approach since it will lead to endless confusion and bikeshedding over what settings need to be forwarded. For example, should --cores affect the remote system? Generally not, except when I want to disable parallelism. So it might be better to allow passing arbitrary settings in the store URI (e.g. --store ssh-ng://foo?cores=1).

Regarding build-related flags, polluting config.hh with an ad-hoc flag for whether to forward certain settings seems ugly to me. In fact it's not clear why we can't just use the existing code for forwarding build-related settings, i.e.

    conn.to << wopSetOptions
       << settings.keepFailed
       << settings.keepGoing
    ...

in RemoteStore::setOptions().

@edolstra We can't reuse the existing code because it forwards things like keepFailed and buildCores unconditionally. Closing in favor of #1948, which gives us a minimal sane base on top of which we can iterate if need be.