We're implementing it though: about:keyboard in a Nightly build does what you expect, this is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=2000731 and dependencies.

Browsers have been doing (sometimes tiered) AOT compilation since wasm inception.

Debian has stopped supporting x86 32bits recently, Chrome did so 9 years or so ago.

We've carefully ran some numbers before doing this, and this affects a few hundreds to a few thousand people (hard to say, ballpark), and most of those people are on 64bits CPUs, but are using a 32bits Firefox or 32bits userspace.

The comparatively high ratio of 32bits users on Windows is not naively applicable to the Linux Desktop population, that has migrated ages ago.

Those methods are sub-sample accurate, granted you call them a bit in advance to account for the cross-thread communication, as you say. But yes, in general this was designed (prior to me becoming an editor) with scheduling in mind, not with low-latency interactivity. That said, it goes quite far.

Other systems go further, such as Web Audio Modules (that builds on top of AudioWorklet) implement sample-accurate parameter change from within the rendering thread, using wait-free ring-buffers. That requires `SharedArrayBuffer` but works great, and is the lowest latency possible (since it uses atomic loads and stores from e.g. the main thread to the rendering thread).

Sorry, I'll implement it, I had forgotten we didn't do it for erm... 9 years.

https://bugzilla.mozilla.org/show_bug.cgi?id=1308431