This applies to every single sandboxed language in the world.
The instructions are designed so that sandboxing the actual core is trivial, and the spec says that you have to sandbox outside of deliberate pass-throughs. That's about the best you can possibly do.
If languages can qualify as sandboxed, it sounds like WASM qualifies. (And if they can't, then we're using a broken definition of "sandboxed".)
Then I stand by what I said before. Your definition is broken, and you're making a semantic argument rather than actually discussing eBPF and WASM.
When you see someone say "sandboxed language" read it as "language where conforming implementations are by definition sandboxed". WASM meets that definition, as far as I can tell.
When you see someone say "WASM is sandboxed" read it as "any runtime that implements the WASM spec is sandboxed".
You can argue that a sandbox might be low quality. That's fine. But it doesn't make it non-sandboxed.
You don't get to decide how an instruction set is used, and a 'low quality sandbox' is not a sandbox.
You've denied facts and continue to make both inexperienced and naieve claims that are dangerous. Not entertaining it further.
When all your security issues are violations of the spec, then it is not the language in the spec that is insecure.
True, but a conforming implementation has at least some sandboxing, since it prevents arbitrary memory access. But the degree to which it is sandboxed depends on the functions that are exposed by the runtime.