since the interface in css-fonts-5 is a strict superset of the one in css-fonts-4, wouldn't it be more robust to patch the former as partial interface?

partial interface CSSFontFaceDescriptors {
  attribute [LegacyNullToEmptyString] CSSOMString fontSize;
  attribute [LegacyNullToEmptyString] CSSOMString font-size;
  attribute [LegacyNullToEmptyString] CSSOMString sizeAdjust;
  attribute [LegacyNullToEmptyString] CSSOMString size-adjust;
  attribute [LegacyNullToEmptyString] CSSOMString superscriptPositionOverride;
  attribute [LegacyNullToEmptyString] CSSOMString superscript-position-override;
  attribute [LegacyNullToEmptyString] CSSOMString subscriptPositionOverride;
  attribute [LegacyNullToEmptyString] CSSOMString subscript-position-override;
  attribute [LegacyNullToEmptyString] CSSOMString superscriptSizeOverride;
  attribute [LegacyNullToEmptyString] CSSOMString superscript-size-override;
  attribute [LegacyNullToEmptyString] CSSOMString subscriptSizeOverride;
  attribute [LegacyNullToEmptyString] CSSOMString subscript-size-override;
}

I suppose it depends on what you mean by "robust"? I'd say CSS Fonts 5 is going to receive more updates than CSS Fonts 4. If the patch is against CSS Fonts 5, it may need to be re-generated more frequently. But hard to predict the future is...

Actually, we could somewhat automate that type of patching: when a delta spec re-defines an interface, we could automatically drop the definition of the interface from the base spec. That's at least theoretically doable, although probably a bit of pain in practice to identify the relevant bits in the IDL extract.

On top of this css-fonts patch, an auto-patching approach would allow us to drop the css-view-transitions patch and, to some extent, the web-animations patch. But maybe it's not worth the hassle?

good point re patching needs; I guess by "robust" I meant that it patched the spec with lesser standing, but that may be more theoretical than practical.

re automating it, I share your question about the cost/benefit ratio - overall, since it's likely to remain mainly a CSS-world issue, I suspect it doesn't quite cross the threshold of being worth it; intuitively, there may be more generically applicable patching infrastructure improvements that would come with better return on investment - said otherwise, if we want to optimize this part of the maintenance process, I think we should try to look at it more generally.