Not for nothing, but this is very much the driving use case behind Parser Augmentation. Syntactic language features can't be polyfilled or even tested for, which means your options as a developer are (a) don't use the new features, (b) consign yourself to always having to transpile your code, or (c) don't support older engines. Even a PA implementation that doesn't support runtime syntax polyfills (in other words, one with a static parser) provides a way for the source text to ask the parser what syntax features are available - you could use it in a similar sort of way as C's #ifdef directive. You could write a single file that parses correctly both as a CJS script using require and module.exports and also as an ES module using import and export, just by including syntax directives to guard the contextually-invalid syntax from the runtime parser.
Of course, this only works if the PA syntax itself is old enough that it's part of the ecosystem baseline, which tends to take around a decade or so. That's why it's so valuable to get it added to the ECMA262 spec now - it might only get minimal runtime support in the near-term, but ten years down the line you'll have an answer for "how do I write a file that supports different versions/variants of ECMAScript syntax?"