On SoC: Any embedded hard core will always be significant long-term vendor lock-in. It won't be easy to migrate for example to embedded RISC-V as it's quite fresh will have to endure all the pain and suffering (at least without extensive GoWin technical support). As open source synthesis support of any hard processor is unlikely, the following can be considered:
1) Separate compute module, for example on CM-style module. CM modules from Raspberry are quite expensive, but alternative suppliers (for example from Orange Pi) can be quite a bit cheaper. Level of community support is varying. CM can output overlay video for example via DSI, which goes into FPGA, forward controllers input via SPI, forward internet and other data via serial port(s). It opens possibility to update system at a later stage, by installing maximum performance CM4 or future CM5 module for cores that will do some significant work on SoC side (for example for emulation of more modern consoles - PS2, and in the future PS3). With CM4/5 - NVMe SSD will be straightforward to support. It is important to have good thermal contact to chassis and/or integrated cooling solution both for CM and FPGA modules, as CM4 is already quite hot (and CM5 will be even hotter).
2) Separate low-end linux module, like Milk-V Duo. No direct video overlay, but rather text ui is sent via SPI or something to FPGA.
3) Soft-core Linux-capable SoC, baked into all cores. For example based on LiteX/VexRiscV. It will eat small part of FPGA, and will work at ~ 15-25% speed of today's hard SoC (~ 150-200Mhz). But it will be completely under our control and portable to any FPGA architecture in the future. As MISTer does not do much computation on SoC side - it can work good enough.
4) Dual FPGA modules: during normal operations one is for soft-core SoC, second for emulation. For maximum capabilities largest cores can utilize both FPGA's. It can be made in a way that there is a minimal configuration with one FPGA module, and it is possible to install second FPGA module for large cores support. Minimal configuration can have smaller FPGA chip, for example 60k LE (to support smaller 8-16-bit cores at lower cost), with second FPGA on a module of full size (138k). So 60K chip can be soldered on the board, and 138K module can be installed later as an upgrade for large cores.
Common for all cases:
DRAM: As we don't need much DRAM by today's standards, does it make sense to remove DDR3 and have more channels of HyperRAM? Such low-latency FPGA module can be produced if we will have large order volume. New module might make sense anyways, if we go with GW5AT chip rather than GW5AST (i.e. without hard SoC, if it is cheaper in high volume).
High-speed IO:Necessity of high-speed interfaces need to be seriously considered. Non-transciever chips are cheaper anyways, and are hard to support especially in opensource. I like NVMe drives, but they are not easy to get working when directly connecting to FPGA. Non-transciever GoWin can go as high as 1.5G on all pins, so maybe even SATA1 for M.2 SSD can work eventually - which can be reliable and fast enough data storage solution.
With no hard IP lock-in and open source synthesis it will be quite easy for amateurs to port MISTer 2.0 to new architectures in the following decades, which might unleash some creative products.