Yes, the nature of the issue is well-understood; the problem is a lack of effort to implement it.  See https://lists.gnu.org/archive/html/mit-scheme-devel/2022-12/msg00001.html for the partial effort I started.  Personally I don't have any systems that require this anyway so it hasn't been a priority for me.

We would certainly have to use this approach, but it's not enough because at any given time you can only toggle between W xor X -- you can't have both set at the same time.

Currently compiled code (executable data) and mutable objects (writable data) are both stored in the same heap.  What we need to do is have a separate heap for compiled code, and whenever we make (or load) compiled code:

1. Toggle the compiled-code heap from executable to writable.
2. Run a GC and move any new compiled-code blocks from the object heap where they were created into the compiled-code heap (GC is needed both to free up unreferenced compiled-code blocks and ensure pointers in the object heap to new compiled-code blocks are relocated to point at the compiled-code heap instead).
3. Toggle the compiled-code heap back from writable to executable.

Other systems like NetBSD will use a slightly different approach: create two virtual address windows into the same anonymous mapping, one mapped executable and the other mapped writable (and maybe only created while the GC is happening).

It's doable, just a pain to deal with all the bookkeeping, which is why I haven't bothered.  (I started drafting some logic to do it back in 2020 but I can't find it now.  Not sure I got far enough to bother looking instead of just starting over, though.)