I'm not much of an expert, but it MIGHT be easier to design this using actual PLL clock-doubling instead of another crystal, as this would give an integer multiplier from the motherboards frequency and this might make things a lot easier to design (also the higher clock would be in sync with the motherboard). Also, I do not have extensive knowledge about how the 8088 woks, but I know a thing or two and if I recall correctly the address and data lines are shared, and the processor sends them in series (first the address, then the data) in any IO or memory read operation. So what might be doable is to wire the processor's data/address+clock lines to an FPGA, and the ones from the motherboard's socket too. Then use the FPGA's PLL capabilities (if any, else put an external PLL circuitry), and operate in two modes: non-turbo - just have the FPGA pass everything through and connect the processor's clock to the original one; turbo - have the FPGA "cache" address and data (as the motherboard won't be able to process them at the higher clock) and inject wait states to the processor to make it wait for the slower bus, and pass the doubled clock.
This should be possible, but one would need to study the 8088's datasheet throughly and be good at FPGA development.

That seems to be way more complicated.

I'd rather have the circuit completely independant from motherboard signals and just rely on the Turbo header. This way in Turbo mode you could keep your high motherboard bus 8 or 10MHz (some XT's do 12) and the top speed for the CPU, 16MHz for a NEC V20HL or even swap the 48MHz crystal on the circuit for a 54MHz one to overclock to 18MHz.

This would give ultimate XT speed without turning the system into a pile of thrash trying to keep speeds in sync. I imagine a 16MHz V20 with a 10MHz bus would give an IBM AT a run for its money.

The problem is that you have to keep things in sync. The processor and motherboard still have to communicate, you can't just toss signals at 16MHz when the motherboard is operating at 8MHz, for example. Doing it your way (no PLL, 48MHz crystal) is actually more complicated as the clocks won't be in sync, and the adapter will have to cope with all that - and yes, it will still have to decode adress/data, cache them and send them to the motherboard through the processor's socket at the motherboar's bus speed.

I had the idea the Intel 8284 clock generator could still generate READY signals for ASYNC operation. The slower motherbus bus would be bottlenecked but still the system would gain some speed.

Nevermind i should have checked datasheets before having ideas... 🤣

From what I understood the READY signal just insers wait states, it won't make the processor hold the address or data lines longer. And the 8284 will just sync its RDY input to the clock. While that might mean that you do not have to control wait states by yourself, I doubt you don't have to deal with the data and address lines.

See if the PC Sprint can be altered to meet your needs:

http://www.brutman.com/pcsprint_annotated.zip

Dave Jones from the EEVBlog made his own clock doubling circuit on his Tandy 1000:

https://www.youtube.com/watch?v=av5NQ_3mW9A

I believe the reason PC Sprint is limited to a 2x speedup on a XT 5160 is that additional wait states are needed to go any faster.
The Turbo XT boards will be inserting wait states already to get to 10Mhz, but I'm guessing you'd need more to go faster.