How would accessing the FPGA through registers instead of instruction opcodes do anything to address the issue of needing to ensure that the FPGA is currently configured to behave in the manner expected by the current process, as opposed to the FPGA still being configured to suit the process that was running before the last context switch?

The fundamental way that an FPGA works (more or less) is to program the configuration registers with values that then determine the routing. One thing you could do is have multiple sets of these configuration registers, at process start you allocate one configuration to that process and set it up, from that point onwards you when you despatch instructions to the functional unit you do it along with the process configuration. So one process could be using the FPGA as a custom hashing function and another could be using it for some funky video IP. I'm not saying it's a guaranteed win but I think there are technical solutions that you could experiment with.

Sounds workable, though you'd also need a way to save and restore any internal state, or else some way to mark off checkpoints where it is interruptible.

The other thing to note is that this only covers using the FPGA for compute. While that's the obvious use-case for an "FPGA in CPU" concept, in the real world, IO is a pretty important part of many non-cryptocurrency FPGA applications, whether you're just counting edges on some input like an encoder, providing a highly time-sensitive output signal, such as for an SDR, or implementing some custom serial protocol.