Consider dropping "compact encoding 2" in text format

[g-plane]

NOTE: This is only for text format, no changes are considered to binary format.

• The "compact encoding 2" looks inconsistent with existing import syntax. Especially, identifier is disallowed in extern type.
• This form makes parser implementation becoming more complex, since parser can't easily guess or predict by peeking (item. Also, there will be more work for checking whether to allow identifier or not when parsing extern type.
• This form makes language server/IDE hard to analyze. In wasm-language-tools, it's easy to analyze the following code:

  (import "env" "a" (global i32))
  (import "env" (item "b" (global i32))

  since each "import" AST node has only one extern type as its child AST node.
  But for:

  (import "env" (item "a") (item "b") (global i32))

  Extern type is no longer a child AST node of the (item) clause, making analysis becoming hard. Also, when user using "Go to definition" in editor for "global a" or "global b", it always points to (global i32) (because that extern type is shared), which is confusing.
• For binary format, "compact encoding 2" can reduce wasm binary size so this makes sense. But for text format, that's not the case. Text format isn't usually for being transferred. Instead, they're the source code of binary format (or decompilation result), so file size isn't a problem.

[rossberg]

Among other things, the text format is for writing tests, so it can't harm to have things like this expressible in it. In general, we want to keep both formats as equivalent as possible, even though that's not 100% the case in every detail.

• The "compact encoding 2" looks inconsistent with existing import syntax. Especially, identifier is disallowed in extern type.

That kind of difference is already the case for other binders, e.g. (param i32) can have an id, but (param i32 i32) cannot. Slightly, but not completely, different situation.

• This form makes parser implementation becoming more complex, since parser can't easily guess or predict by peeking (item. Also, there will be more work for checking whether to allow identifier or not when parsing extern type.

True, but it is not hard to implement, e.g., the latter with a flag for allowing the identifier. There surely are worse offences in the text format. :)

• Extern type is no longer a child AST node of the (item) clause, making analysis becoming hard. Also, when user using "Go to definition" in editor for "global a" or "global b", it always points to (global i32) (because that extern type is shared), which is confusing.

I don't understand how this could affect analysis, since it's purely a surface syntax thing — a parser can always desugar it into the "old" AST if that's more convenient. Similarly wrt definitions, the desugaring would inherit the location of the item.