Stand alone FPGA solutions have existed for years already - there are myrads of boards and systems available, and for which variants of Minimig implementation runs fine already, with and without AGA support. The Apollo project is not about this.
OK. Right, and compatibility with other FPGA solutions is excellent and/or improving. Compatibility with older software is high priority, with good reason.
This statement does not say Phoenix, it is about FPGA solutions in general:
Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.
I don't think that then the FPGA solution or the Phoenix/Apollo core is then really what you are looking for. Yes, it can be turned off so the system runs then on a plain 68K CPU with native speed... In the same sense a fast 68060@50 is not really helpful for running old games. If I want to, I disable the turbo board and run the stuff on the 68000 in my A2000.
Same as for the 68060, the FPGA speed is probably too much for many badly written games in first place. The general guideline is that if the game is Os-friendly, it should usually run. But only few games are, and most authors did not really know well enough what they were doing.
WHDload is a combination of patching techniques, both into the game and into the Os, to fix the most obvious bugs the games had, but it seems very likely that *if* you want to make games run on the FPGA with WHDLoad (why? just use the 68K in the system anyhow...) then WHDLoad would have to support the whole FPGA core natively by a couple of support functions. As said, I would rather believe that the MMU is then probably the least problem.
Right. Again, you can't "switch off" the FPGA in a standalone FPGA product. As I mentioned above, having the options for a performance (less compatible) core, and an option to choose an accurate (more compatible) core is fine - but for the product to be successful I believe a standalone FPGA product needs high compatibility one way or another.
Counter to your original statement, I think an FPGA solution is PERFECT for a scenario like this where you have the ability to switch cores depending on what you need at a given time.