Multiple different _referencingScriptOrModule_, _specifier_ pairs may map to the same Module Record instance. The actual mapping semantic is implementation-defined but typically a normalization process is applied to _specifier_ as part of the mapping process. A typical normalization process would include actions such as alphabetic case folding and expansion of relative and abbreviated path specifiers.
+Multiple different _referencingScriptOrModule_, _specifier_ _moduleRequest_.[[Specifier]] pairs may map to the same Module Record instance. The actual mapping semantic is implementation-defined but typically a normalization process is applied to _specifier_ as part of the mapping process. A typical normalization process would include actions such as alphabetic case folding and expansion of relative and abbreviated path specifiers.
The above text implies that, if a module is imported multiple times with different _moduleRequest_.[[Attributes]] values, then there can be just one possible "successful" value (possibly as a result of multiple different attributes), but that it can also fail with an exception thrown; this exception from one import does not rule out success with a different attribute list.
+The restriction of of attributes to not affect the contents of the module or be part of the cache key is sometimes referred to as permitting only "check attributes" and not "evaluator attributes", where the latter would change the contents of the module. Future versions of this specification may relax this restriction, and it's understood that some hosts may be tempted to willfully violate this restriction, but the module attributes champion group advises caution with such a move. There are three possible ways to handle multiple imports of the same module with different attributes, if the attributes cause a change in the interpretation of the module:
+It's possible that one of these three options may make sense for a module load, on a case-by-case basis by attribute, but it's worth careful thought before making this choice.
+The above text implies that, if a module is imported multiple times with different _type_ values, then there can be just one possible "successful" value (possibly as a result of multiple different types), but that it can also fail with an exception thrown; this exception from one import does not rule out success with a different type.
The above text implies that hosts *must* support JSON modules imported with `type: "json"` (if it completes normally), but it doesn't prohibit hosts from supporting JSON modules imported with no type specified. Some environments (for example, web browsers) are expected to require `with type: "json"`, and environments which want to restrict themselves to a compatible subset would do so as well.