Not sure how that might work. To run compiled RP2040 SDK C PIO code on a PIO "clone" inside an FPGA you are going to have to do a ton of work. That's kind of where I was going with my question. By the time you do all that work to use an FPGA you might as well implement the functionality in hardware.
I love FPGA's...and yet I hate them with a passion. When they are the right fit for the job you can't beat them. However, this comes at a pretty serious cost in terms of debug cycles per day, troubleshooting complexity and just plain time. I am known for saying that developing a solution on an FPGA takes "cubic time" when compared to other options.
I have worked on a number of projects where compile times are in excess of an hour and debugging is excruciatingly painful. You need an 18 hour day just to iterate through two to four attempts at fixing a problem. Like I said, painful.
These days I avoid them as much as possible or, when necessary, I prefer to license well-designed and well-tested cores that just work.
FPGAs are obviously cool and powerful, but there's a pretty big cost differential.
On top of that, an FPGA is not a replacement for a CPU in itself. Soft cores are costly in gates. Of course "FPGA + CPU" is a thing, but in that case... if you can get away with a CPU by itself your tooling gets a lot simpler.
If you are talking about creating microcoded state machines in an FPGA, once again, this is the kind of thing that is almost trivial. Examples of subsystems can can be implemented this way are dynamic RAM controllers, sophisticated programmable image processors/scalers, etc.