(This issue captures the presentation at CG-03-02, with the goal of getting more feedback in preparation for a poll at some future CG meeting.)

The Module Linking proposal proposes to recast two-level imports as sugar for single-level imports of instances. For example:

(module
  (import "a" "foo" (func))
  (import "a" "bar" (func))
)

would be desugared to the same AST as:

(module
  (import "a" (instance
    (export "foo" (func))
    (export "bar" (func)))
)

One problem with this is that currently wasm allows duplicate imports (with the same or different signatures):

(module
  (import "a" "b" (func))
  (import "a" "b" (func))
)

while duplicate exports are disallowed. Thus, desugaring the above to:

(module
  (import "a" (instance
    (export "b" (func))
    (export "b" (func)))
)

would not be valid. module-linking/#7 discusses various ways to reconcile this discrepancy, but the simplest solution would be to retroactively disallow duplicate imports.

Bug 1647791 added telemetry to measure duplicate imports in Firefox, and the results for Firefox Beta 86 show 0.00014% of page loads contain duplicate imports (which may just be unit tests in automation or other synthetic sources). Thus, it seems like this is a breaking change we could practically make.

Another principled reason to disallow duplicate imports is that duplicate imports with differing signatures can only be implemented by the host which breaks the general goal of allowing wasm to always be able to virtualize (polyfill, mock, etc) wasm imports.

On concrete bit of experience is that the spec test suite used to have duplicate imports (for different "overloads" of the print function), but this was removed because it caused problems for people wanting to run the tests.

Thus, it could be argued that this restriction is generally a good one for the wasm ecosystem, even setting aside the concerns of the Module Linking proposal.