So even if all possible runtimes have to be sandboxed or they're not actually implementing the language, it's not possible for a language to qualify as "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".

If wasm had a standard runtime everyone used, sure. It doesn't, runtimes are significantly fragmented. Therefore 'wasm is sandboxed' is not true, and in many cases those sandboxes are not at all being audited. It is very dangerous to make broad and demonstrably untrue statements about software security. Wasm is not a sandbox, wasm is a set of instructions. Your quality of sandbox, if at all, is up to what runtime you use. No amount of word play will change that.

The defined semantics for those instructions include sandboxing. If there is no sandbox, it's not WASM. It wouldn't be implementing the instructions as described in the spec.

You can argue that a sandbox might be low quality. That's fine. But it doesn't make it non-sandboxed.

"if there is no sandbox then it's not wasm".

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.

If someone guesses what all the instructions are supposed to do and implements the wrong semantics, they didn't actually implement the same instruction set!

When all your security issues are violations of the spec, then it is not the language in the spec that is insecure.