Would it make sense to also add aria-level when `:heading()` selector is not supported?

Working with headingoffset implies that styling headings with <h1> to <h6> selectors only in no longer viable.
The solution is to switch to the new :heading() function instead...

So current styling for a heading level 2 would e.g. look like this:

:heading(2) {
 /* heading 2 style with native support for headingoffset and :heading() */
}

@supports not selector(:heading(2)) {
  h2:where(:not([aria-level])),
  :is(h1, h2, h3, h4, h5, h6):where([aria-level="2"]) {
    /* fallback when headingoffset is not supported, but the polyfill is active */
  }
}

This works as long as browser release support :heading() function ahead of headingoffset or both together.

• Firefox Nightly currently supports both. So is uses the modern style
• Firefox, Chrome and Safari stable both use the polyfill and the CSS fallback
• Chrome Canary on the other hand has a working implementation of headingoffset, but not :heading() yet, so there is no way to properly apply heading styles.

So the CodePen Demo currently looks like this in Chrome/Edge Canary:

While it should look like this:

So the question is, would it make sense to update the polyfill to still apply aria-level when headingoffset is supported, but :heading() is not?

Start by reproducing the Chrome/Edge Canary behavior using the linked CodePen, then inspect the polyfill's handling of headingoffset and aria-level. Determine how to cover browsers with headingoffset but without :heading(); done means the heading level 2 fallback is styled correctly in that environment without breaking the existing native-support and polyfill fallbacks.