Supporting generating Wasm modules is probably a good idea.
I think this would be a different build mode, like c-archive or c-shared on other platforms, that generates a library instead of an executable. The library can be "loaded"/"linked" at later time. Maybe we just reuse one of them, although it is not really "c".
Right now //go:linkname is needed to work-around the "missing function body" issue, and in case of TinyGo, it's used to change the function name in import in the WASM output, but yeah, if the linker had first-class support for WASM, then this shouldn't be necessary.
I could see a value in adding //go:wasm_import function_name [module_name] to make the dynamic import explicit, and to avoid any name clashes with resolved imports. Basically, a WASM-equivalent of //go:cgo_import_dynamic (which I couldn't figure out how to abuse to make it work for WASM).
Note that imports in WASM have both: module name and function name, so it would be great if one could specify both, with "env" being the default if no module name was provided.