But this also causes options like the sandbox or remote build configuration to be forwarded to the SSH host. In particular, forwarding the builders option would be quite bad because it could cause infinite build forwarding.

Isn't that argument true for all the remote stores? I think it would be best if the RemoteStore::setOptions would filter those options then so we get unified capabilities.

In practice I used --builders ssh-ng:// and didn't notice the infinite build forwarding issue so maybe the option isn't forwarded already.

See #1946.

Sending everything makes ssh-ng unusable except if the source and target machines have the exact same sandbox-paths since that includes a store path. Especially problematic if the target is another platform.

Note that RemoteStore is a misnomer. It was actually originally not remote at all: it's the local store accessed via the daemon. So in that case having the same configuration makes sense.

Thanks, I will be loading all of the context tomorrow

Yeah that approach is not going to work.

1. the protocol behind setOptions needs to be re-thought so only a subset of the options can be passed
2. the options need to be classified so only build options are forwarded (eg: the various timeout options, sandbox-enable, ...). Or pass them to the remote builder URI as query string options like eelco suggested.