Do not going harassing developers because you think they are doing it wrong. If you can do better and don't want to actually contribute to the upstream you are always free to fork it.
In my first proper job as a software engineer I wrote a bunch of Forth for "fruit machines". I don't know what the US equivalent would be but they are low stakes gambling machines which are quite common in UK pubs. The core processor was a 6809 and Forth was chosen because the interpreter was super small and easy to implement. I really appreciated the quick interactive way you could update and tweak code as you tested it. I did get slightly weary of having to keep the state of the stack in your head as you DUP and SWAP stuff around but that was probably due to my inexperience and not decomposing things enough.
They continued to use Forth as the basis for their 68000 based video gaming machines although when it came to the hand classifier for video poker we ended up using C - mostly because we wanted to run a lot of simulations on one of these new fangled "Pentium" processors to make sure we got the prize distribution right to meet the target repayment rate of ~98%.
The talks have also now gone up on the YouTube channel: https://www.youtube.com/@kvmforum6546/videos including my keynote based on top QEMU stories in Hacker News for the year ;-)
The plugins have access to the instruction stream to make architecture specific decisions. What I meant by architecture independent is that it doesn't involve per-guest annotations in the frontends to handle - any guest using the common translator loop (which is all of them now) can be instrumented by plugins.
However I absolutely agree its not currently as full featured as we would like. The next step when I get time is re-factoring the handling of register values in the core QEMU code so we can expose them to the plugins in a clean API.
The upstream now has TCG plugins (https://qemu.readthedocs.io/en/latest/devel/tcg-plugins.html) which allow for a degree of instrumentation. The implementation is architecture agnostic and also tested within the code base. There are still features missing but it does provide a base for dynamic analysis of guest code.
AIUI that is mainly achieved by running the native library functions.Given how much time you spend in library functions I'm not surprised it has an edge over the full translation of the application.
Since v4.0.0 (see https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a94b783952cc...). We are always up for improving the code generation quality but of course there is a trade off with JITs given we are not compilers. I suspect there are still big wins if we can come up with a reasonable solution for re-generating a hot-path of basic blocks with much better optimisation.
We do use the host FPU for a subset of floating point operations now. However it only really works for clean 32/64 IEEE FP so anything that goes through the x87 still needs software emulation.
I should point out that the awesome part of this work is unlike a lot of academic exercises this was done in collaboration with the community. As a result much of the work is merged upstream and QEMU gets to benefit.