We already have two infrastructures to do that: the JavaScript engine and wasm.

And, indeed, part of the deprecation of XSLT proposal involves, in essence, moving XSLT processing from the browser-native layer to wasm as a polyfill that a site author can opt into.

Yes, what I meant (one way to handle what the author proposed; possibly not exactly what they meant) is that many of these "building blocks" can be made from wasm (although I have some criticism of that too, nevertheless, it will do), and many will be included by default, and others would be set up by the user if desired. Native code extensions (e.g. .so files) would also be possible but is not needed for most things, and if you set up from the app store or from stuff specified by the document or server then only sandboxed VM codes would be possible and native codes would not be allowed in those circumstances.