Sounds good. For now my emphasis is on the low level. I definitely need support to get the high level right.
I have had discussions with @ericzinda on a new general JSON representation for Prolog terms. The idea is to create something where the terms you normally like to transfer (lists, strings, numbers, objects) come pretty natural, but the representation has escapes that allow for faithful round trip of arbitrary Prolog terms.
One thing at a time 
Auto yield is in the planning and probably fairly easy. Roughly means doing the same as calling js_yield/2 automatically each Nth increment of the inference counter. A more serious problem is that yielding from any position in the VM is probably not that easy and that is what would be required to yield for debugger interactions. Another complication is that in the current design there is a significant number of places where Prolog is called through C, e.g., C → Prolog → C → Prolog → … Yielding from there would require a general mechanism to yield in C. Does that exist? It might be possible using stack copying? You need to think outside the C standard, so even if it can work for C, can it work for WASM?
As I see it now, auto-yielding will surely be added. Hopefully yield for the debugger is possible. If not we have two alternatives: a debugger as meta-interpreter or a debugger based on recording the actions and replaying them. Possibly some of the C → Prolog → C → Prolog calls can be avoided or we can extend the C in the middle to save/restore its state such that we can yield through the callback.