unicode-range and falling off the end of the font-family list

Start with the CSS Fonts 4 sections on cluster matching, system fonts, and installed fonts linked in the issue. Compare the three proposed interpretations with current browser behavior and the specification terminology. Done means reaching a resolved normative direction and identifying the corresponding spec wording to update.

Consider content like this:

@font-face {
    font-family: MyCoolWebFont;
    src: url("someFontThatActuallySupportsTheLetterE.ttf");
    unicode-range: something that doesn't contain the letter e;
}
...
<div style="font-family: 'MyCoolWebFont';">e</div>

The relevant section of the spec is this: https://drafts.csswg.org/css-fonts-4/#cluster-matching

1. For each family in the font list, a face is chosen using the style selection rules defined in the previous section.
   ....
2. If no font was found in the font list in step 1:
   1. If c1 is a variation selector, ...
   2. Otherwise, the user agent may optionally use system font fallback ...
3. If no font is found in step 2, use the matching sequence from step 1 to determine the longest sequence that is completely supported by a font ...

Step 1 clearly shouldn't select any fonts. The only one listed in the font-family list has a unicode-range that doesn't include the character being rendered. Okay.

Step 2.1 is clearly irrelevant.

Step 2.2 uses the term "system font" which is clearly wrong. "System font" is defined in section 10.4 as "the font which is used by the system-ui generic font family name."

Is step 2.2 allowed to use someFontThatActuallySupportsTheLetterE.ttf? It supports the letter e, and we fell off the end of the fallback list, where we're ostensibly allowed to use any font at this point.

When browsers have fallen off the end of the fallback list and they're trying to find some font to use, it's fairly common practice for browsers to use the first font in the font-family list as a hint, to try to find a used font that's as "close" to the hint font as possible. If the hint font itself supports the target character, then it seems not totally unreasonable to just use the hint font itself to render the character.

Options

There are probably 3 options here:

1. Say normatively that a @font-face with unicode-range must never, in any circumstances, be used to render a character outside of its unicode-range character set.
2. Say normatively that step 2 must only be allowed to return an installed font.
3. Add no restrictions; once the browser falls off the end of the font-family list, all bets are off, it can use any font accessible to the document, including web fonts.

I'm not super sure, but it might be true that options 1 and 2 are behaviorally identical to each other.