#176 changed the behavior around invalid URLs. i.e.

{"imports": { "https://example.com/foo": "https://:invalid:url" }}

is equal to

• {"imports": {}} after Slim down to a minimal core #176, i.e. "https://example.com/foo" remains unmapped (i.e. import maps can't be used to force-reject specifier resolution), while
• {"imports": { "https://example.com/foo": null }} before Slim down to a minimal core #176, i.e. resolving "https://example.com/foo" fails.

What was the reason behind this change?

Does this mean that, after #176, when we re-enable fallback/built-in modules support again:

1. {"imports": { "https://example.com/foo": "https://:invalid:url" }} is equal to {"imports": {}} as a direct result of the change Slim down to a minimal core #176,
2. {"imports": { "https://example.com/foo": ["https://:invalid:url"] }} is equal to {"imports": {}} for keeping equivalence between "https://:invalid:url" and ["https://:invalid:url"] that held before Slim down to a minimal core #176,
3. {"imports": { "https://example.com/foo": [] }} is equal to {"imports": {}},
4. {"imports": { "https://example.com/foo": null }} is different from {"imports": { "https://example.com/foo": [] }}

?

Context: Chromium will keep fallback implementation behind built-in modules flag, even after #176, and thus I'd like to clarify the background/implication of #176 to the fallback mechanism.
I'm neutral about the new/old behaviors.