How to store / load exported environment variables to / from a file

You can write the environment to a file with export -p and read it back periodically in the other instances with . (the include command). But as you note, if there are concurrent modifications, the result won't be pretty.

If you want modifications to propagate instantly, you'll have to use a wrapper around the export builtin that also propagates the changes to the other shells. On Linux, you can use the flock utility.

global_export () {
  {
    flock 0
    . /path/to/env
    [ $# -eq 0 ] || export "$@"
    export -p >/path/to/env
  } </path/to/env
}

Note that you'll need to call global_export whenever you assign a new value to an exported variable.

This is rather clumsy. It's likely that there's a better way to solve your problem. The most obvious way is to have whatever command is using those environment variable read a configuration files instead.

SSH has a feature to pass environment variables from the client to the server, but OpenSSH disables it in the default server configuration. There's one exception: TERM, which has a special place in the protocol; but communicating information via TERM is awkward because you have to be sure that the client will decode it.

Nevertheless some servers are configured to let some environment variables through. For example, Debian configures the SSH server to allow all variables whose name begins with LC_. Usually these are locale variables, but you can put whatever you like.

If the server isn't configured to allow any variable, you can pass them as part of the command, but there are a couple of wrinkles. The wrinkle you're hitting is that if you pass a command to ssh, then by default no terminal is created on the server. So ssh frobozz@for.example.com FOO=$FOO zsh does in fact run a shell, but that shell is connected to a pipe, not to a terminal, so it doesn't display a prompt or support command line edition. Nonetheless, you can type commands — try typing ls Enter, and exit Enter or Ctrl+D to exit. The solution is to explicitly tell SSH to open a terminal, with the -t option.

ssh -t frobozz@for.example.com FOO=$FOO zsh

Depending on what your login shell is, you may want to run

ssh -t frobozz@for.example.com FOO=$FOO exec zsh

to avoid having an extra shell process that's the parent of that explicitly-invoked zsh.

The second problem you haven't run into yet is quoting. The SSH protocol transmits a string which is executed by the remote shell. Here, you're passing the string consisting of FOO=, followed by the value of FOO, followed by a space and exec zsh. Thus the value of FOO is interpreted as a bit of shell source code, not as a string to store in the FOO variable. This makes a difference if the value contains characters that have a special meaning in shell syntax. You need to add an extra level of quoting. Assuming your local shell is zsh, you can use the q parameter expansion flag:

ssh -t frobozz@for.example.com FOO=${(q)FOO} exec zsh

Another difference with the straight case is that you're first running a login shell on the remote side, and then replacing it with a non-login shell. Since the chain starts with a login shell (this cannot be avoided), your .profile or .zprofile does get run; however the interactive instance of zsh is not a login shell, which might make a difference depending on the content of your dot files. The best solution for that is probably to avoid doing fragile things in your dot files. You can run zsh -l, but that runs a second login shell, which is prone to making more of a difference (though you can fix that, too, by making sure that your .profile or .zprofile is idempotent).