PR #48 chooses option (3). But we could just as well do any of the others. Interestingly it would seem that the examples in the overview are still well-typed with this change; the "init"-tracking of locals works out for us.

Thinking about this a bit more, with regards to the dimensions of performance and binary size:

• It doesn't matter if a stringref instruction consumes a nullable operand. If the generator of the wasm wants to use non-nullable strings, it can, and no null check will be emitted in that case. Or the generator can decide not to and it will get null checks. Not a huge deal.
• Producing non-nullable types makes sense, because otherwise generators that want non-nullable types will have to downcast. Granted, an optimizing compiler will remove these, but it's annoying and adds to binary size.

Of course, it still doesn't make sense to consume a null operand :P I still have the feeling that if we have a shorthand, that it should nudge people in the right direction, and so stringref should be non-nullable.

In the GC proposal we standardized on shorthands always denoting nullable references, so it would be good to be consistent with that choice here.

The GC proposal's operations also generally accept nullable inputs and produce non-nullable outputs (where possible), so it would be good (for both consistency and binary size) to do the same here.

Related to the concept of "generally accept[ing] nullable inputs", it would be good to clarify whether the array parameters consumed by string.{new,encode}_*_array are nullable (I assume they are, but the current text in Overview.md doesn't make that clear).