В эпоху, где браузеры сами обновляются, это не проблема... У обычного человека всегда будет обновлённый браузер с необходимым функционалом, а тех, кто использует что-то старое, вся ответственность лежит на них... Для них следует вывести напоминание, что пора обновиться, как это делает, например, YouTube и множество других сайтов!

И как это сделать для WASM или WebGL? Правильное решение — предложить обновиться до последней версии. Это не сложно!

Я, например, не вижу такой необходимости, если вам везде нужна стабильная работа приложения, то вы сами можете использовать нужный браузерный движок! Например, Electron используют Skype, VS Code и пр.

А между тем большинство тех, кто начинает сегодня программировать, скорей всего не сталкивались с IE. И правда, где можно встретить IE? Молодой человек покупает телефон/планшет/ноутбук, разве там такое есть? Даже я его только видел только в виртуальной машине, когда запустил там ради интереса Windows XP. Знаете, этот ваш IE — это лицорука и развод пенсионерами! Там даже CSS нормально не работает! Вы должны радоваться, что больше нет такого мерзкого браузера, а не думать, как туда что-то транспилировать!

Транспилять всё равно надо. Потому что typescript. Потому что vue sfc. Sass. CSS modules... И т.д. и т.п.
Без транспиляния нынче как без штанов.

А при чем тут приложение?
Просто код в браузере. На простой ваниле.
Я, например, довольно широко использую WeakMap.
Есть у нас некоторые внутренние библиотеки, где на них многое держится.
Навешиваются на элемент DOM некоторые дополнительные массивы данных. Если элемент удаляется, то не приходится думать, что эти данные застрянут в памяти и не будут убраны сборщиком мусора.

А можно с тем же успехом по старинке навешивать на элемент DOM некоторые дополнительные массивы данных... (буквально)

Плохо смотрел. Это не JavaScript. И вообще какие мотивы движут людьми, которые напишут что-то на TypeScript и дают имени файла расширение .js (вместо .ts)? С# тоже местами похож на JS, однако ни у кого не возникает желания косить под JS! 😜😜

Если это вам так важно, то приложение как раз гарантирует, что ваш WeakMap всегда сработает, а сайт могут открыть (почему-то) в старом браузере.

Какая ложная аналогия! Вы вполне можете писать на стандартном JS и всё нормально будет работать.

Навешивать прямо на DOM не хорошо. Нельзя в чужой объект пихать свои поля. Нет никакой гарантии, что когда-нибудь производитель браузера не введет туда поле с таким же именем.
Есть легенда, что тип Symbol появился как раз из за этого. Когда захотели ввести итераторы, то первая мысль была ввести в массивы и разные другие объекты служебное поле iterator (ну как есть length у разных объектов) Выяснилось, что существует довольно много библиотек, которые внедряют в прототипы стандартных объектов поля и методы с этим и другими именами. Пришлось вводить новый тип, который гарантированно никто не использует.

И не «по старинке» тоже...

const array = Symbol();
node[array] = [];

Да, тип Symbol именно для этого и предназначен!

Объявление переменных при помощи var было доступно как в ES3, так и доступно до сих пор в ES2020. Конечно в большинстве случаев вам достаточно let с его блочной видимостью, однако когда вам не нужна блочная видимость, то как раз подходит var — например, два последовательных цикла, второй из которых использует переменные инициализированные (при помощи var) в первом цикле.

Если у вас долгоиграющий проект, то у вас был сайт (например, написанный в одну кучу на PHP), а теперь вы, например, хотите сделать его как «одностраничное» приложение (SPA). Не спешите разрушать или дефрагментировать диски со старым проектом, вы можете его перенести с https://example.com/ на https://example.com/olddesign. А по адресу https://example.com/ разместить свой новый проект, в котором будет проверка на нужные API, в случае их отсутствия, будет перенаправление на https://example.com/olddesign.

А если проект совсем новый, то и беспокоится не о чем... 😂 😂 😂 ни у кого из пользователей нет опыта работы с приложением через старый браузер, так что вы можете им спокойно продавать теорию о том, что нужен новый браузер! Поверьте, они купятся и скачают! 😉

Тут недавно дошло до смешного. Написал довольно большой модуль (т.к. мы можем в своей работе не думать про всякие ИЕ и прочее старье) то использовал те возможности, которые считал более удобными. Решил его минифицировать с помощью гугл клаши.
Не тут то было. Выдает ошибку за ошибкой. Оказывается клаша не распознает синтаксис полей классов, которые были введены еще в 72-ом Хроме (а сейчас уже 80-й)

Ну не красиво. Запариваешся эти скобки постоянно писать.
К тому же иногда думаешь об оптимизации (хотя по большому выигрыш, наверно, в наносекундах)
V8 при оптимизации многие функции компилирует в машинный код. При выполнении ряда условий. Например вызов этой функции должен всегда происходить с параметрами одного типа. Как выяснилось если параметр объект, то {а: , b: }, {a:, b:, c:}, {b:, a:} - это уже разные типы

А ещё когда-то в «Кроум» (Chrome — это вам не «Хроме») были введены HTML imports, которые потом были благополучно выпилены. Не всё, что есть в Chrome — стандартизировано, и соответственно может исчезнуть! Полей классов не было в ECMAScript2019, соответственно и не поддерживается в Closure Compiler.

Поля классов даже в этом году скорей всего не войдут в стандарт!

Это стандартный синтаксис для определения поля при помощи символа. Тоже самое вам придётся сделать, если имя вычисляемое!