I think this PR is fine, happy with it if it satisfies @sffc.

I do not think however it solves the original problem, because the original problem is not well-defined (what kind of string you expect as "valid text" depends on a per-import context). Arguably, "it's a String" and "it's textual data" mean the same thing, so in my point of view what this PR writes is just a tautology.

A description that more closely matches what Shane is asking for (but is not enforceable) would probably be:

It creates a Synthetic Module Record whose default export is source, a String value that should represent data from the space of possible strings that the user considers to contain valid code units in the context the string is going to be used.

I'm happy with the section of ECMA-262 that @eemeli cited: "The String type is generally used to represent textual data in a running ECMAScript program". This is ECMA-262 accomplishing both of the following:

1. Stating that the String type is largely designed for "textual data"; and also
2. Acknowledging that the String type does not necessarily contain "textual data", i.e. it is not a "tautology" as @nicolo-ribaudo suggests.

Note: The line between "binary data" and "textual data" is fairly clear. There are a multitude of ways to define it, whether technically (something based on code points) or semantically (something that contains content that humans can read if they need to). We might consider a separate editorial change to write a more proper definition of "textual data".

I'm happy with the section of ECMA-262 that @eemeli cited: "The String type is generally used to represent textual data in a running ECMAScript program".

@sffc Could you clarify if this means that you don't think this PR's change is needed, as we already have the language you're looking for in the spec?

I'm happy with the section of ECMA-262 that @eemeli cited: "The String type is generally used to represent textual data in a running ECMAScript program".

@sffc Could you clarify if this means that you don't think this PR's change is needed, as we already have the language you're looking for in the spec?

My intent with the word "happy" was to emphasize that I was glad to see you citing the pre-existing language in your PR body.

I would like this PR to land because it asks hosts to give us strings that contain textual data ("good" Strings) and not those that contain non-textual data ("bad" Strings).