From 899979bad03d8f494d69de173deb3da834d3025c Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 30 Sep 2026 20:37:58 -0400
Subject: [PATCH 1/5] Bulid time feature flags (draft)

---
 text/0000-build-time-feature-flags.md | 252 ++++++++++++++++++++++++++
 1 file changed, 252 insertions(+)
 create mode 100644 text/0000-build-time-feature-flags.md

diff --git a/text/0000-build-time-feature-flags.md b/text/0000-build-time-feature-flags.md
new file mode 100644
index 0000000000..14b2e62f8b
--- /dev/null
+++ b/text/0000-build-time-feature-flags.md
@@ -0,0 +1,252 @@
+---
+stage: accepted
+start-date: 2026-09-30T00:00:00.000Z
+release-date:
+release-versions:
+teams:
+  - cli
+  - framework
+  - learning
+prs:
+  accepted: # Fill this in with the URL for the Proposal RFC PR
+project-link:
+suite:
+---
+
+
+# Build-time Feature Flags
+
+## Summary
+
+`ember-source` reads every flag from `import.meta.env?.EMBER_*`, and from nowhere else:
+
+```js
+// @ember/-internals/environment
+export const DEFAULT_ASYNC_OBSERVERS = import.meta.env?.EMBER_DEFAULT_ASYNC_OBSERVERS ?? true;
+```
+
+The bundler replaces the expression with a literal.
+Every read of `DEFAULT_ASYNC_OBSERVERS` then folds to a constant, and the minifier removes the code that the app does not use.
+This covers canary features, optional features, `EmberENV`, and deprecations that can remove their code early.
+
+Existing config files keep working, because the build reads them and turns them into `import.meta.env` values.
+Minimal apps with no config files get a way to set flags for the first time.
+The runtime global `window.EmberENV` stops being a source of flags.
+
+## Motivation
+
+Ember has three places to configure the framework, and all three are runtime-only:
+
+| Source | Where the app sets it | How `ember-source` reads it |
+| --- | --- | --- |
+| Canary features | `EmberENV.FEATURES` in `config/environment.js` | `isEnabled('FLAG')` from `@ember/canary-features` |
+| Optional features | `config/optional-features.json` | `@ember/optional-features` copies the values into `EmberENV` |
+| `EmberENV` | `config/environment.js` | `ENV` from `@ember/-internals/environment` |
+
+All three end up in `window.EmberENV`.
+In an app with `@embroider/compat`, Embroider writes the `EmberENV` object from `config/environment.js` into `/@embroider/virtual/vendor.js`, which runs before Ember loads.
+Because the values arrive at runtime, every branch ships to every user.
+An app that turned on `default-async-observers` years ago still downloads the sync observer path.
+[RFC 1234](./1234-deprecate-ember-object.md) adds a flag that turns off `EmberObject`, but the code still ships until the build can remove it.
+
+A build-time value alone does not fix this.
+Assume that `ember-source` reads a flag from `import.meta.env` and falls back to `window.EmberENV`.
+Then each flag that the build does not set still depends on a runtime value, and both branches stay.
+One source of truth is a requirement for dead-code removal.
+
+Vite, Rolldown, esbuild, and Rollup all replace `import.meta.env.*` with literals at build time.
+If Ember reads its flags from `import.meta.env`, then the tools that apps already use can remove dead code, with no Ember-specific plugin in the minifier.
+
+Minimal apps have no path at all.
+The [`v2-app-hello-world-template`](https://github.com/emberjs/ember.js/tree/main/smoke-tests/v2-app-hello-world-template) in the ember.js repo and the `minimal-app` output of [`ember.nvp`](https://github.com/NullVoxPopuli/ember.nvp) have no `@embroider/compat`, no `config/environment.js`, and no `vendor.js`.
+The `ember.nvp` output has an `EmberENV: {}` key in `app/config.ts`, but nothing copies it to `window.EmberENV`, so it has no effect.
+The only way for these apps to set a flag today is a hand-written `window.EmberENV` assignment that runs before the first import of `ember-source`.
+
+`ember-source` already uses this pattern internally.
+`@glimmer/local-debug-flags` reads `import.meta.env?.VM_LOCAL_DEV`.
+
+## Detailed design
+
+### The read pattern
+
+Each flag is one exported `const`, and `ENV` is built from those constants:
+
+```js
+// @ember/-internals/environment
+export const FLAG = import.meta.env?.EMBER_FLAG ?? <default>;
+export const FEATURE_FOO_BAR = import.meta.env?.EMBER_FEATURE_FOO_BAR ?? false;
+
+export const ENV = {
+  FLAG,
+  FEATURES: { FOO_BAR: FEATURE_FOO_BAR },
+};
+```
+
+Code in `ember-source` imports the `const`, and does not read `ENV.FLAG`.
+`ENV` stays for Ember Inspector and for `isEnabled`, and it holds the same values.
+
+- `import.meta.env?.` uses optional chaining because some environments do not define `import.meta.env`. Examples: a plain `<script type="module">`, an import map, or Node without a bundler. In those environments the expression is `undefined`, and the default applies.
+- The default lives next to the flag in `ember-source`. This is how Ember decides if a flag is opt-in or opt-out, per flag.
+
+A property read does not fold reliably.
+Vite 7 (Rollup) folds `ENV.X` only while nothing writes to `ENV` and `ENV` does not escape through `getENV()`.
+Vite 8 (Rolldown) does not fold `ENV.X` at all, even when the object is never written to.
+Both versions fold a `const` export.
+
+Two more changes follow from one source of truth:
+
+1. The `for (flag in EmberENV)` loop that copies `window.EmberENV` into `ENV` goes away.
+2. Nothing writes to `ENV`. For example, `@ember/application` sets `ENV.LOG_VERSION = false` so that the version logs once. That state moves to a module-local variable.
+
+Values are JSON: booleans for most flags, and a number or string for the few that need it (`EMBER_RERENDER_LOOP_LIMIT`, `EMBER_OVERRIDE_DEPRECATION_VERSION`).
+
+### Names
+
+The name is `EMBER_` plus the existing name in `SCREAMING_SNAKE_CASE`, with the leading underscore removed.
+
+| Today | Build-time name |
+| --- | --- |
+| `EmberENV.FEATURES.FOO_BAR` | `EMBER_FEATURE_FOO_BAR` |
+| `default-async-observers` in `optional-features.json` | `EMBER_DEFAULT_ASYNC_OBSERVERS` |
+| `EmberENV.LOG_VERSION` | `EMBER_LOG_VERSION` |
+| `EmberENV._DEBUG_RENDER_TREE` | `EMBER_DEBUG_RENDER_TREE` |
+| `EmberENV._ALL_DEPRECATIONS_ENABLED` | `EMBER_ALL_DEPRECATIONS_ENABLED` |
+
+Canary features get a `FEATURE_` segment, because their names are free-form and can collide with `EmberENV` keys.
+
+### How an app sets a flag
+
+Existing config keeps working, and it also becomes build-time config.
+The `ember()` Vite plugin from `@embroider/vite` reads `config/optional-features.json` and the `EmberENV` object from `config/environment.js`, and it defines the matching `import.meta.env.EMBER_*` values.
+So an existing app gets smaller output after it upgrades, with zero changes.
+These files are inputs to the build, and `ember-source` never reads them at runtime.
+
+An app can also set flags with the tools that Vite users already know:
+
+```bash
+# .env
+EMBER_DEBUG_RENDER_TREE=false
+```
+
+```js
+// vite.config.mjs
+export default defineConfig({
+  define: {
+    'import.meta.env.EMBER_LOG_INSPECTOR_HINT': 'false',
+  },
+});
+```
+
+`EMBER_DEBUG_RENDER_TREE=false` removes the debug render tree from the build, in development too.
+Today `_DEBUG_RENDER_TREE` defaults to `DEBUG`, and development builds force it to `true`, so the code always ships.
+An app that does not use Ember Inspector or `captureRenderTree` does not need it.
+
+The `ember()` plugin reads `EMBER_*` keys from `.env` files and defines each one as a JSON value.
+Plain Vite gives `.env` values to the app as strings, so `EMBER_DEBUG_RENDER_TREE=false` is the string `"false"`, and that string is truthy.
+Without the `ember()` plugin, use `define`.
+If `config/environment.js` and `.env` or `define` set the same flag, `define` wins, then `.env`, then `config/environment.js`.
+
+#### Minimal apps
+
+A minimal app has no `config/environment.js` and no `optional-features.json`, so there is nothing for the build to read.
+It sets flags with `.env` or `define`, the same way it sets any other Vite config, and every flag that it does not set gets the default from `ember-source`.
+Generators for minimal apps, such as `ember.nvp`, remove the `EmberENV` key from `app/config.ts`, because it does nothing.
+
+### Canary features
+
+Today `isEnabled('FLAG')` reads `FEATURES`, which merges `DEFAULT_FEATURES` with `EmberENV.FEATURES` through `Object.assign`.
+The public `FEATURES` export from `@ember/canary-features` is also documented as an object that apps can add to before they create the application.
+Each canary feature becomes a `FEATURE_*` constant, with its default next to it, as the read pattern above shows.
+`ember-source` code imports `FEATURE_FOO_BAR` and does not call `isEnabled('FOO_BAR')`, because a function call with a string argument does not fold to a constant.
+`isEnabled` stays public and reads `ENV.FEATURES`.
+A write to `FEATURES` at runtime has no effect on `ember-source`, and development builds throw an error that names the `EMBER_FEATURE_*` flag to set instead.
+
+For beta and release builds of `ember-source`, the ember.js build replaces `import.meta.env?.EMBER_FEATURE_*` with the value that the release channel ships.
+Unfinished features are then absent from the published tarball, same as today.
+
+### Optional features
+
+On `main`, `ember-source` only reads one optional feature at runtime: `default-async-observers`, through `ENV._DEFAULT_ASYNC_OBSERVERS`.
+The others are either removed ([RFC 704](./0704-deprecate-octane-optional-features.md), [RFC 705](./0705-deprecate-jquery-optional-feature.md)) or have no remaining runtime check.
+`EMBER_DEFAULT_ASYNC_OBSERVERS` replaces the runtime read, and `optional-features.json` keeps working through the Vite plugin.
+
+The default for `EMBER_DEFAULT_ASYNC_OBSERVERS` changes from `false` to `true`, because the app blueprint already turns it on.
+An app that does not list `default-async-observers` in `optional-features.json` has sync observers today, so for that app the `ember()` plugin defines `false` and behavior does not change.
+The `true` default applies to new apps and to builds that do not use the plugin.
+
+> [!NOTE]
+> Observers are deprecated ([RFC #1115](https://github.com/emberjs/rfcs/pull/1115)), and v8 removes them.
+> `EMBER_DEFAULT_ASYNC_OBSERVERS` goes away with them.
+
+This RFC does not deprecate `@ember/optional-features`.
+A later RFC can do that when nothing in `ember-source` reads it.
+
+### `EmberENV`
+
+Each key in `ENV` from `@ember/-internals/environment` gets an `EMBER_*` name from the table rule above, and an initializer that follows the read pattern.
+
+`ember-source` no longer reads `window.EmberENV`.
+For most apps this is not visible, because Embroider fills `window.EmberENV` from the same `config/environment.js` that the `ember()` plugin reads.
+An app that sets `window.EmberENV` in its own `<script>`, or changes it after the build, loses those values.
+Development builds compare `window.EmberENV` with `ENV`, and they throw an error for each key that does not match, with the `EMBER_*` flag to set instead.
+
+### Sveltable deprecations
+
+This RFC does not change how deprecations work.
+`DEPRECATIONS`, `deprecateUntil`, and the `isEnabled` and `isRemoved` values stay as they are.
+
+Some deprecations come with a flag that removes the deprecated feature before the major version that removes it.
+This RFC calls them sveltable deprecations.
+The first one is `deprecate-ember-object` from [RFC 1234](./1234-deprecate-ember-object.md).
+
+Each sveltable deprecation gets a `const` that follows the read pattern.
+The name is `EMBER_DEPRECATION_` plus the deprecation `id` in `SCREAMING_SNAKE_CASE`:
+
+```js
+export const DEPRECATION_DEPRECATE_EMBER_OBJECT =
+  import.meta.env?.EMBER_DEPRECATION_DEPRECATE_EMBER_OBJECT ?? false;
+```
+
+When the value is `true`, the deprecated feature is gone, and the minifier removes its code.
+The default is `false` until the major version where the deprecation RFC turns the flag on by default.
+A deprecation with no flag in its RFC gets no `EMBER_DEPRECATION_*` constant.
+
+### Ecosystem
+
+- Addons: v2 addons can use the same `import.meta.env?.` pattern for their own flags. This RFC does not define a naming rule for them.
+- `ember-auto-import`: webpack does not define `import.meta.env` by default. `ember-auto-import` must define the `EMBER_*` values from `config/environment.js` and `config/optional-features.json`. If it does not, classic apps get the defaults and lose their config, so this is a requirement before `ember-source` ships the change.
+- Without a bundler, `ember-source` uses the defaults. There is no way to set a flag in that environment.
+- SSR and FastBoot: no change. The server bundle gets the same defines as the browser bundle.
+- Ember Inspector: no change. It reads `ENV`, which still holds the resolved values.
+- TypeScript: `ember-source` declares the `EMBER_*` keys on `ImportMetaEnv`, so the keys autocomplete in `vite.config.mjs` and in app code.
+- Blueprints: the app blueprint keeps `config/optional-features.json` and `EmberENV`. No blueprint change is necessary for this RFC.
+
+## How we teach this
+
+The guides page for [feature flags](https://guides.emberjs.com/release/configuring-ember/feature-flags/) and the page for optional features change to show `.env` and `define` first, with `config/environment.js` as the classic option.
+
+The message for app developers is short: set flags where you set other build config, and Ember ships less code.
+
+The deprecation guide for each sveltable deprecation adds one line with the name of its `EMBER_DEPRECATION_*` flag.
+
+## Drawbacks
+
+- Apps that set `window.EmberENV` outside of `config/environment.js` must move that config into the build. The error in development builds finds each case, but it is still a change for those apps.
+- A flag cannot change at runtime. A test suite that toggles a flag needs one build per value, the same way the ember.js CI runs `ALL_DEPRECATIONS_ENABLED` today.
+- Every supported build must define the `EMBER_*` values. A build that does not define them silently falls back to defaults.
+- Without a bundler, there is no way to set a flag.
+- Dead-code removal depends on a rule that a type checker does not enforce: code reads the `const`, not `ENV.X`. The ember.js repo needs a test that builds `v2-app-hello-world-template` with flags set and checks the output for the removed code.
+- A sveltable deprecation flag lets an app remove code that an addon still calls. The app finds out at runtime, not at build time.
+
+## Alternatives
+
+- `@embroider/macros` (`getOwnConfig`, `macroCondition`). This works today, but it is Ember-specific and requires Babel. `import.meta.env` is the ecosystem standard, and every modern bundler supports it.
+- `process.env.EMBER_*`. Older convention, and it throws in the browser without a bundler. `import.meta.env?.` does not throw.
+- Keep `window.EmberENV` as a runtime fallback: `import.meta.env?.EMBER_X ?? EmberENV.X ?? <default>`. No app loses config, but each flag then has two sources of truth. Any flag that the build does not set keeps both branches, and the Inspector and the debugger can show a different value than the build config.
+- Do nothing. Apps keep paying for code paths that they turned off.
+
+## Unresolved questions
+
+- Vite 7 and Vite 8 replace the optional-chained form `import.meta.env?.X`. Does webpack do the same?
+- Does `ember-auto-import` define `import.meta.env` today, or does it need a new release first?
+- Is an error in development builds enough for apps that set `window.EmberENV` at runtime, or does that case need a deprecation cycle that ends in the next major?

From 9472ba1925125f7f3218abc2ef3c02ff1d99738c Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 30 Sep 2026 20:42:32 -0400
Subject: [PATCH 2/5] small changes towards the end

---
 text/0000-build-time-feature-flags.md | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/text/0000-build-time-feature-flags.md b/text/0000-build-time-feature-flags.md
index 14b2e62f8b..0d372f2a98 100644
--- a/text/0000-build-time-feature-flags.md
+++ b/text/0000-build-time-feature-flags.md
@@ -225,28 +225,20 @@ A deprecation with no flag in its RFC gets no `EMBER_DEPRECATION_*` constant.
 
 The guides page for [feature flags](https://guides.emberjs.com/release/configuring-ember/feature-flags/) and the page for optional features change to show `.env` and `define` first, with `config/environment.js` as the classic option.
 
-The message for app developers is short: set flags where you set other build config, and Ember ships less code.
-
-The deprecation guide for each sveltable deprecation adds one line with the name of its `EMBER_DEPRECATION_*` flag.
+The deprecation guides for each sveltable deprecation should document which enviranment variable to set in order to remove the deprecated code.
 
 ## Drawbacks
 
 - Apps that set `window.EmberENV` outside of `config/environment.js` must move that config into the build. The error in development builds finds each case, but it is still a change for those apps.
-- A flag cannot change at runtime. A test suite that toggles a flag needs one build per value, the same way the ember.js CI runs `ALL_DEPRECATIONS_ENABLED` today.
-- Every supported build must define the `EMBER_*` values. A build that does not define them silently falls back to defaults.
+- A flag cannot change at runtime. A test suite that toggles a flag needs one build per value, the same way the ember.js CI runs `ALL_DEPRECATIONS_ENABLED` today (using `define`, you can bring back EmberENV / runtime behavior, however).
+- Every supported build must define the `EMBER_*` values if those builds want non-defaults. 
 - Without a bundler, there is no way to set a flag.
-- Dead-code removal depends on a rule that a type checker does not enforce: code reads the `const`, not `ENV.X`. The ember.js repo needs a test that builds `v2-app-hello-world-template` with flags set and checks the output for the removed code.
-- A sveltable deprecation flag lets an app remove code that an addon still calls. The app finds out at runtime, not at build time.
 
 ## Alternatives
 
 - `@embroider/macros` (`getOwnConfig`, `macroCondition`). This works today, but it is Ember-specific and requires Babel. `import.meta.env` is the ecosystem standard, and every modern bundler supports it.
-- `process.env.EMBER_*`. Older convention, and it throws in the browser without a bundler. `import.meta.env?.` does not throw.
-- Keep `window.EmberENV` as a runtime fallback: `import.meta.env?.EMBER_X ?? EmberENV.X ?? <default>`. No app loses config, but each flag then has two sources of truth. Any flag that the build does not set keeps both branches, and the Inspector and the debugger can show a different value than the build config.
 - Do nothing. Apps keep paying for code paths that they turned off.
 
 ## Unresolved questions
 
-- Vite 7 and Vite 8 replace the optional-chained form `import.meta.env?.X`. Does webpack do the same?
-- Does `ember-auto-import` define `import.meta.env` today, or does it need a new release first?
-- Is an error in development builds enough for apps that set `window.EmberENV` at runtime, or does that case need a deprecation cycle that ends in the next major?
+n/a

From 359b9faea6f790be7c93de80326b4a338418c85a Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 30 Sep 2026 20:50:46 -0400
Subject: [PATCH 3/5] frontmatter

---
 ...d-time-feature-flags.md => 1247-build-time-feature-flags.md} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename text/{0000-build-time-feature-flags.md => 1247-build-time-feature-flags.md} (99%)

diff --git a/text/0000-build-time-feature-flags.md b/text/1247-build-time-feature-flags.md
similarity index 99%
rename from text/0000-build-time-feature-flags.md
rename to text/1247-build-time-feature-flags.md
index 0d372f2a98..e5aef2c856 100644
--- a/text/0000-build-time-feature-flags.md
+++ b/text/1247-build-time-feature-flags.md
@@ -8,7 +8,7 @@ teams:
   - framework
   - learning
 prs:
-  accepted: # Fill this in with the URL for the Proposal RFC PR
+  accepted: https://github.com/emberjs/rfcs/pull/1247
 project-link:
 suite:
 ---

From a82b338a53c9b85d4cbab4f3b913a32d5453121a Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Wed, 30 Sep 2026 20:55:28 -0400
Subject: [PATCH 4/5] de-llm

---
 text/1247-build-time-feature-flags.md | 192 ++++++++------------------
 1 file changed, 56 insertions(+), 136 deletions(-)

diff --git a/text/1247-build-time-feature-flags.md b/text/1247-build-time-feature-flags.md
index e5aef2c856..3570b58e33 100644
--- a/text/1247-build-time-feature-flags.md
+++ b/text/1247-build-time-feature-flags.md
@@ -35,93 +35,42 @@ The runtime global `window.EmberENV` stops being a source of flags.
 
 ## Motivation
 
-Ember has three places to configure the framework, and all three are runtime-only:
+Today, all of Ember's flags are read at runtime from `window.EmberENV`, so every branch ships to every user:
+- an app that turned on `default-async-observers` years ago still ships the sync observer path
+- an app that turns off `EmberObject` ([RFC 1234](./1234-deprecate-ember-object.md)) would still ship `EmberObject`
 
-| Source | Where the app sets it | How `ember-source` reads it |
-| --- | --- | --- |
-| Canary features | `EmberENV.FEATURES` in `config/environment.js` | `isEnabled('FLAG')` from `@ember/canary-features` |
-| Optional features | `config/optional-features.json` | `@ember/optional-features` copies the values into `EmberENV` |
-| `EmberENV` | `config/environment.js` | `ENV` from `@ember/-internals/environment` |
+A build-time value with a runtime fallback (`import.meta.env?.X ?? EmberENV.X`) does not fix this, because any flag that the build does not set keeps both branches.
+Dead-code removal requires one source of truth.
 
-All three end up in `window.EmberENV`.
-In an app with `@embroider/compat`, Embroider writes the `EmberENV` object from `config/environment.js` into `/@embroider/virtual/vendor.js`, which runs before Ember loads.
-Because the values arrive at runtime, every branch ships to every user.
-An app that turned on `default-async-observers` years ago still downloads the sync observer path.
-[RFC 1234](./1234-deprecate-ember-object.md) adds a flag that turns off `EmberObject`, but the code still ships until the build can remove it.
-
-A build-time value alone does not fix this.
-Assume that `ember-source` reads a flag from `import.meta.env` and falls back to `window.EmberENV`.
-Then each flag that the build does not set still depends on a runtime value, and both branches stay.
-One source of truth is a requirement for dead-code removal.
-
-Vite, Rolldown, esbuild, and Rollup all replace `import.meta.env.*` with literals at build time.
-If Ember reads its flags from `import.meta.env`, then the tools that apps already use can remove dead code, with no Ember-specific plugin in the minifier.
-
-Minimal apps have no path at all.
-The [`v2-app-hello-world-template`](https://github.com/emberjs/ember.js/tree/main/smoke-tests/v2-app-hello-world-template) in the ember.js repo and the `minimal-app` output of [`ember.nvp`](https://github.com/NullVoxPopuli/ember.nvp) have no `@embroider/compat`, no `config/environment.js`, and no `vendor.js`.
-The `ember.nvp` output has an `EmberENV: {}` key in `app/config.ts`, but nothing copies it to `window.EmberENV`, so it has no effect.
-The only way for these apps to set a flag today is a hand-written `window.EmberENV` assignment that runs before the first import of `ember-source`.
-
-`ember-source` already uses this pattern internally.
-`@glimmer/local-debug-flags` reads `import.meta.env?.VM_LOCAL_DEV`.
+Minimal apps, such as [`v2-app-hello-world-template`](https://github.com/emberjs/ember.js/tree/main/smoke-tests/v2-app-hello-world-template) and the [`ember.nvp`](https://github.com/NullVoxPopuli/ember.nvp) `minimal-app`, have no `config/environment.js` and no `@embroider/virtual/vendor.js`, so they have no way to set a flag at all.
 
 ## Detailed design
 
-### The read pattern
-
-Each flag is one exported `const`, and `ENV` is built from those constants:
+Each flag is an exported `const`, and `ENV` is built from those:
 
 ```js
 // @ember/-internals/environment
-export const FLAG = import.meta.env?.EMBER_FLAG ?? <default>;
+export const DEFAULT_ASYNC_OBSERVERS = import.meta.env?.EMBER_DEFAULT_ASYNC_OBSERVERS ?? true;
+export const DEBUG_RENDER_TREE = import.meta.env?.EMBER_DEBUG_RENDER_TREE ?? DEBUG;
 export const FEATURE_FOO_BAR = import.meta.env?.EMBER_FEATURE_FOO_BAR ?? false;
 
 export const ENV = {
-  FLAG,
+  _DEFAULT_ASYNC_OBSERVERS: DEFAULT_ASYNC_OBSERVERS,
+  _DEBUG_RENDER_TREE: DEBUG_RENDER_TREE,
   FEATURES: { FOO_BAR: FEATURE_FOO_BAR },
 };
 ```
 
-Code in `ember-source` imports the `const`, and does not read `ENV.FLAG`.
-`ENV` stays for Ember Inspector and for `isEnabled`, and it holds the same values.
-
-- `import.meta.env?.` uses optional chaining because some environments do not define `import.meta.env`. Examples: a plain `<script type="module">`, an import map, or Node without a bundler. In those environments the expression is `undefined`, and the default applies.
-- The default lives next to the flag in `ember-source`. This is how Ember decides if a flag is opt-in or opt-out, per flag.
-
-A property read does not fold reliably.
-Vite 7 (Rollup) folds `ENV.X` only while nothing writes to `ENV` and `ENV` does not escape through `getENV()`.
-Vite 8 (Rolldown) does not fold `ENV.X` at all, even when the object is never written to.
-Both versions fold a `const` export.
-
-Two more changes follow from one source of truth:
-
-1. The `for (flag in EmberENV)` loop that copies `window.EmberENV` into `ENV` goes away.
-2. Nothing writes to `ENV`. For example, `@ember/application` sets `ENV.LOG_VERSION = false` so that the version logs once. That state moves to a module-local variable.
-
-Values are JSON: booleans for most flags, and a number or string for the few that need it (`EMBER_RERENDER_LOOP_LIMIT`, `EMBER_OVERRIDE_DEPRECATION_VERSION`).
-
-### Names
+- The `?.` is for environments without `import.meta.env` (plain `<script type="module">`, import maps, Node). Those get the default.
+- The default sits next to each flag, which decides if the flag is opt-in or opt-out.
+- Internal code imports the `const`, not `ENV.X`. Vite 8 (Rolldown) does not fold property reads, even on an object that nothing writes to. Both Vite 7 and Vite 8 fold a `const`.
+- `ENV` stays (for the Inspector and `isEnabled`), but nothing writes to it, and the `for (flag in EmberENV)` merge goes away.
 
-The name is `EMBER_` plus the existing name in `SCREAMING_SNAKE_CASE`, with the leading underscore removed.
+The name is `EMBER_` plus the existing name in `SCREAMING_SNAKE_CASE`, without the leading underscore.
+Canary features get `FEATURE_` because their names are free-form.
+Values are JSON (`EMBER_RERENDER_LOOP_LIMIT` is a number, for example).
 
-| Today | Build-time name |
-| --- | --- |
-| `EmberENV.FEATURES.FOO_BAR` | `EMBER_FEATURE_FOO_BAR` |
-| `default-async-observers` in `optional-features.json` | `EMBER_DEFAULT_ASYNC_OBSERVERS` |
-| `EmberENV.LOG_VERSION` | `EMBER_LOG_VERSION` |
-| `EmberENV._DEBUG_RENDER_TREE` | `EMBER_DEBUG_RENDER_TREE` |
-| `EmberENV._ALL_DEPRECATIONS_ENABLED` | `EMBER_ALL_DEPRECATIONS_ENABLED` |
-
-Canary features get a `FEATURE_` segment, because their names are free-form and can collide with `EmberENV` keys.
-
-### How an app sets a flag
-
-Existing config keeps working, and it also becomes build-time config.
-The `ember()` Vite plugin from `@embroider/vite` reads `config/optional-features.json` and the `EmberENV` object from `config/environment.js`, and it defines the matching `import.meta.env.EMBER_*` values.
-So an existing app gets smaller output after it upgrades, with zero changes.
-These files are inputs to the build, and `ember-source` never reads them at runtime.
-
-An app can also set flags with the tools that Vite users already know:
+### Setting flags
 
 ```bash
 # .env
@@ -132,111 +81,82 @@ EMBER_DEBUG_RENDER_TREE=false
 // vite.config.mjs
 export default defineConfig({
   define: {
-    'import.meta.env.EMBER_LOG_INSPECTOR_HINT': 'false',
+    'import.meta.env.EMBER_DEBUG_RENDER_TREE': 'false',
   },
 });
 ```
 
-`EMBER_DEBUG_RENDER_TREE=false` removes the debug render tree from the build, in development too.
-Today `_DEBUG_RENDER_TREE` defaults to `DEBUG`, and development builds force it to `true`, so the code always ships.
-An app that does not use Ember Inspector or `captureRenderTree` does not need it.
-
-The `ember()` plugin reads `EMBER_*` keys from `.env` files and defines each one as a JSON value.
-Plain Vite gives `.env` values to the app as strings, so `EMBER_DEBUG_RENDER_TREE=false` is the string `"false"`, and that string is truthy.
-Without the `ember()` plugin, use `define`.
-If `config/environment.js` and `.env` or `define` set the same flag, `define` wins, then `.env`, then `config/environment.js`.
+Either one removes the whole debug render tree, in development too.
+Today it always ships, because development builds force it on.
 
-#### Minimal apps
+The `ember()` plugin from `@embroider/vite`:
+- reads `config/environment.js` (`EmberENV`) and `config/optional-features.json`, and defines the matching `EMBER_*` values. Existing apps get smaller builds with no changes.
+- parses `.env` values as JSON. Plain Vite gives the string `"false"`, which is truthy, so without the plugin, use `define`.
+- resolves conflicts as `define`, then `.env`, then `config/environment.js`.
 
-A minimal app has no `config/environment.js` and no `optional-features.json`, so there is nothing for the build to read.
-It sets flags with `.env` or `define`, the same way it sets any other Vite config, and every flag that it does not set gets the default from `ember-source`.
-Generators for minimal apps, such as `ember.nvp`, remove the `EmberENV` key from `app/config.ts`, because it does nothing.
+Minimal apps have no config files, so they use `.env` or `define` like any other Vite config.
+Generators can drop the `EmberENV` key from `app/config.ts` (in `ember.nvp`, nothing reads it).
 
-### Canary features
+### `window.EmberENV`
 
-Today `isEnabled('FLAG')` reads `FEATURES`, which merges `DEFAULT_FEATURES` with `EmberENV.FEATURES` through `Object.assign`.
-The public `FEATURES` export from `@ember/canary-features` is also documented as an object that apps can add to before they create the application.
-Each canary feature becomes a `FEATURE_*` constant, with its default next to it, as the read pattern above shows.
-`ember-source` code imports `FEATURE_FOO_BAR` and does not call `isEnabled('FOO_BAR')`, because a function call with a string argument does not fold to a constant.
-`isEnabled` stays public and reads `ENV.FEATURES`.
-A write to `FEATURES` at runtime has no effect on `ember-source`, and development builds throw an error that names the `EMBER_FEATURE_*` flag to set instead.
+`ember-source` no longer reads `window.EmberENV`.
+Most apps won't notice, because Embroider fills it from the same `config/environment.js` that the plugin reads.
+Apps that set it by hand lose those values.
+For those, development builds throw an error for each mismatched key, naming the `EMBER_*` flag to use.
 
-For beta and release builds of `ember-source`, the ember.js build replaces `import.meta.env?.EMBER_FEATURE_*` with the value that the release channel ships.
-Unfinished features are then absent from the published tarball, same as today.
+The same goes for runtime writes to `FEATURES` from `@ember/canary-features`.
+`isEnabled` stays public, but internal code uses the `FEATURE_*` constants, because `isEnabled('FOO')` can't fold.
+Beta and release builds of `ember-source` replace `EMBER_FEATURE_*` with the channel's value, so unfinished features stay out of the tarball (same as today).
 
 ### Optional features
 
-On `main`, `ember-source` only reads one optional feature at runtime: `default-async-observers`, through `ENV._DEFAULT_ASYNC_OBSERVERS`.
-The others are either removed ([RFC 704](./0704-deprecate-octane-optional-features.md), [RFC 705](./0705-deprecate-jquery-optional-feature.md)) or have no remaining runtime check.
-`EMBER_DEFAULT_ASYNC_OBSERVERS` replaces the runtime read, and `optional-features.json` keeps working through the Vite plugin.
-
-The default for `EMBER_DEFAULT_ASYNC_OBSERVERS` changes from `false` to `true`, because the app blueprint already turns it on.
-An app that does not list `default-async-observers` in `optional-features.json` has sync observers today, so for that app the `ember()` plugin defines `false` and behavior does not change.
-The `true` default applies to new apps and to builds that do not use the plugin.
+`default-async-observers` is the only optional feature that `ember-source` still reads.
+Its default becomes `true`, matching the app blueprint.
+Apps that don't list it in `optional-features.json` have sync observers today, so for them the plugin defines `false`.
 
 > [!NOTE]
-> Observers are deprecated ([RFC #1115](https://github.com/emberjs/rfcs/pull/1115)), and v8 removes them.
-> `EMBER_DEFAULT_ASYNC_OBSERVERS` goes away with them.
-
-This RFC does not deprecate `@ember/optional-features`.
-A later RFC can do that when nothing in `ember-source` reads it.
-
-### `EmberENV`
+> Observers are deprecated ([RFC #1115](https://github.com/emberjs/rfcs/pull/1115)) and removed in v8, along with `EMBER_DEFAULT_ASYNC_OBSERVERS`.
 
-Each key in `ENV` from `@ember/-internals/environment` gets an `EMBER_*` name from the table rule above, and an initializer that follows the read pattern.
-
-`ember-source` no longer reads `window.EmberENV`.
-For most apps this is not visible, because Embroider fills `window.EmberENV` from the same `config/environment.js` that the `ember()` plugin reads.
-An app that sets `window.EmberENV` in its own `<script>`, or changes it after the build, loses those values.
-Development builds compare `window.EmberENV` with `ENV`, and they throw an error for each key that does not match, with the `EMBER_*` flag to set instead.
+`@ember/optional-features` is not deprecated by this RFC.
 
 ### Sveltable deprecations
 
-This RFC does not change how deprecations work.
-`DEPRECATIONS`, `deprecateUntil`, and the `isEnabled` and `isRemoved` values stay as they are.
-
-Some deprecations come with a flag that removes the deprecated feature before the major version that removes it.
-This RFC calls them sveltable deprecations.
-The first one is `deprecate-ember-object` from [RFC 1234](./1234-deprecate-ember-object.md).
+How deprecations work does not change.
 
-Each sveltable deprecation gets a `const` that follows the read pattern.
-The name is `EMBER_DEPRECATION_` plus the deprecation `id` in `SCREAMING_SNAKE_CASE`:
+Some deprecations come with a flag that removes the deprecated feature before the major that removes it (for example, `deprecate-ember-object` from [RFC 1234](./1234-deprecate-ember-object.md)).
+These get a `const` named after the deprecation `id`:
 
 ```js
 export const DEPRECATION_DEPRECATE_EMBER_OBJECT =
   import.meta.env?.EMBER_DEPRECATION_DEPRECATE_EMBER_OBJECT ?? false;
 ```
 
-When the value is `true`, the deprecated feature is gone, and the minifier removes its code.
-The default is `false` until the major version where the deprecation RFC turns the flag on by default.
-A deprecation with no flag in its RFC gets no `EMBER_DEPRECATION_*` constant.
+`true` removes the code.
+The default stays `false` until the major where that deprecation's RFC turns it on.
 
 ### Ecosystem
 
-- Addons: v2 addons can use the same `import.meta.env?.` pattern for their own flags. This RFC does not define a naming rule for them.
-- `ember-auto-import`: webpack does not define `import.meta.env` by default. `ember-auto-import` must define the `EMBER_*` values from `config/environment.js` and `config/optional-features.json`. If it does not, classic apps get the defaults and lose their config, so this is a requirement before `ember-source` ships the change.
-- Without a bundler, `ember-source` uses the defaults. There is no way to set a flag in that environment.
-- SSR and FastBoot: no change. The server bundle gets the same defines as the browser bundle.
-- Ember Inspector: no change. It reads `ENV`, which still holds the resolved values.
-- TypeScript: `ember-source` declares the `EMBER_*` keys on `ImportMetaEnv`, so the keys autocomplete in `vite.config.mjs` and in app code.
-- Blueprints: the app blueprint keeps `config/optional-features.json` and `EmberENV`. No blueprint change is necessary for this RFC.
+- `ember-auto-import` must define the `EMBER_*` values from the config files, or classic apps lose their config. This is required before `ember-source` ships the change.
+- v2 addons can use the same pattern for their own flags.
+- TypeScript: `ember-source` declares the `EMBER_*` keys on `ImportMetaEnv`.
+- SSR, FastBoot, and the Inspector: no change.
 
 ## How we teach this
 
-The guides page for [feature flags](https://guides.emberjs.com/release/configuring-ember/feature-flags/) and the page for optional features change to show `.env` and `define` first, with `config/environment.js` as the classic option.
+The [feature flags](https://guides.emberjs.com/release/configuring-ember/feature-flags/) and optional features guides show `.env` and `define` first, and `config/environment.js` as the classic option.
 
-The deprecation guides for each sveltable deprecation should document which enviranment variable to set in order to remove the deprecated code.
+The deprecation guide for each sveltable deprecation documents which environment variable removes the deprecated code.
 
 ## Drawbacks
 
-- Apps that set `window.EmberENV` outside of `config/environment.js` must move that config into the build. The error in development builds finds each case, but it is still a change for those apps.
-- A flag cannot change at runtime. A test suite that toggles a flag needs one build per value, the same way the ember.js CI runs `ALL_DEPRECATIONS_ENABLED` today (using `define`, you can bring back EmberENV / runtime behavior, however).
-- Every supported build must define the `EMBER_*` values if those builds want non-defaults. 
+- Apps that set `window.EmberENV` outside of `config/environment.js` must move that config into the build. The error in development builds finds each case.
+- A flag can't change at runtime, so a test suite that toggles a flag needs one build per value, like the ember.js CI does for `ALL_DEPRECATIONS_ENABLED` today. (With `define`, you can bring back runtime behavior, however.)
+- Every build that wants non-defaults must define the `EMBER_*` values.
 - Without a bundler, there is no way to set a flag.
 
 ## Alternatives
 
-- `@embroider/macros` (`getOwnConfig`, `macroCondition`). This works today, but it is Ember-specific and requires Babel. `import.meta.env` is the ecosystem standard, and every modern bundler supports it.
+- `@embroider/macros` (`getOwnConfig`, `macroCondition`). Works today, but it is Ember-specific and requires Babel. `import.meta.env` is the ecosystem standard.
 - Do nothing. Apps keep paying for code paths that they turned off.
 
 ## Unresolved questions

From 261fd037666eb5148a9a404ac006f04ea401d474 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Sat, 3 Oct 2026 12:49:49 -0400
Subject: [PATCH 5/5] Updates

---
 text/1247-build-time-feature-flags.md | 116 ++++++++++++--------------
 1 file changed, 52 insertions(+), 64 deletions(-)

diff --git a/text/1247-build-time-feature-flags.md b/text/1247-build-time-feature-flags.md
index 3570b58e33..90ed0ce98b 100644
--- a/text/1247-build-time-feature-flags.md
+++ b/text/1247-build-time-feature-flags.md
@@ -18,20 +18,22 @@ suite:
 
 ## Summary
 
-`ember-source` reads every flag from `import.meta.env?.EMBER_*`, and from nowhere else:
+`ember-source` reads each flag with the literal expression `import.meta.env?.EMBER_*`:
 
 ```js
-// @ember/-internals/environment
-export const DEFAULT_ASYNC_OBSERVERS = import.meta.env?.EMBER_DEFAULT_ASYNC_OBSERVERS ?? true;
+if (import.meta.env?.EMBER_SYNC_OBSERVERS) {
+  // sync observer path
+}
 ```
 
-The bundler replaces the expression with a literal.
-Every read of `DEFAULT_ASYNC_OBSERVERS` then folds to a constant, and the minifier removes the code that the app does not use.
-This covers canary features, optional features, `EmberENV`, and deprecations that can remove their code early.
+The bundler replaces the expression with a literal, and the minifier removes the branch.
+Each flag defaults to falsy, so an app that sets nothing gets the default behavior.
 
-Existing config files keep working, because the build reads them and turns them into `import.meta.env` values.
+`EmberENV`, `config/environment.js`, and optional features work the same until v8.
+`EMBER_DROP_LEGACY_CONFIG_ENV` removes that code now.
 Minimal apps with no config files get a way to set flags for the first time.
-The runtime global `window.EmberENV` stops being a source of flags.
+
+A separate RFC will be needed for deprecations of the old styles of flagging.
 
 ## Motivation
 
@@ -39,49 +41,39 @@ Today, all of Ember's flags are read at runtime from `window.EmberENV`, so every
 - an app that turned on `default-async-observers` years ago still ships the sync observer path
 - an app that turns off `EmberObject` ([RFC 1234](./1234-deprecate-ember-object.md)) would still ship `EmberObject`
 
-A build-time value with a runtime fallback (`import.meta.env?.X ?? EmberENV.X`) does not fix this, because any flag that the build does not set keeps both branches.
-Dead-code removal requires one source of truth.
+While `ember-source` reads `EmberENV` at runtime, the build cannot remove either branch.
+`EMBER_DROP_LEGACY_CONFIG_ENV` removes that read, so `import.meta.env` becomes the one source of truth.
 
 Minimal apps, such as [`v2-app-hello-world-template`](https://github.com/emberjs/ember.js/tree/main/smoke-tests/v2-app-hello-world-template) and the [`ember.nvp`](https://github.com/NullVoxPopuli/ember.nvp) `minimal-app`, have no `config/environment.js` and no `@embroider/virtual/vendor.js`, so they have no way to set a flag at all.
 
 ## Detailed design
 
-Each flag is an exported `const`, and `ENV` is built from those:
-
-```js
-// @ember/-internals/environment
-export const DEFAULT_ASYNC_OBSERVERS = import.meta.env?.EMBER_DEFAULT_ASYNC_OBSERVERS ?? true;
-export const DEBUG_RENDER_TREE = import.meta.env?.EMBER_DEBUG_RENDER_TREE ?? DEBUG;
-export const FEATURE_FOO_BAR = import.meta.env?.EMBER_FEATURE_FOO_BAR ?? false;
-
-export const ENV = {
-  _DEFAULT_ASYNC_OBSERVERS: DEFAULT_ASYNC_OBSERVERS,
-  _DEBUG_RENDER_TREE: DEBUG_RENDER_TREE,
-  FEATURES: { FOO_BAR: FEATURE_FOO_BAR },
-};
-```
-
+- Each read is the literal expression `import.meta.env?.EMBER_SOME_FEATURE`. No module re-exports a flag or gives it a second name, so a build tool only needs expression replacement to remove dead code.
+- Each flag defaults to falsy. A flag turns on a non-default behavior.
+- When a major makes an optional behavior the default, its flag goes away. If the old behavior stays available, it gets a new flag.
 - The `?.` is for environments without `import.meta.env` (plain `<script type="module">`, import maps, Node). Those get the default.
-- The default sits next to each flag, which decides if the flag is opt-in or opt-out.
-- Internal code imports the `const`, not `ENV.X`. Vite 8 (Rolldown) does not fold property reads, even on an object that nothing writes to. Both Vite 7 and Vite 8 fold a `const`.
-- `ENV` stays (for the Inspector and `isEnabled`), but nothing writes to it, and the `for (flag in EmberENV)` merge goes away.
 
-The name is `EMBER_` plus the existing name in `SCREAMING_SNAKE_CASE`, without the leading underscore.
-Canary features get `FEATURE_` because their names are free-form.
+Names are `EMBER_` plus `SCREAMING_SNAKE_CASE`.
 Values are JSON (`EMBER_RERENDER_LOOP_LIMIT` is a number, for example).
 
+| Flag | Effect |
+| --- | --- |
+| `EMBER_DROP_LEGACY_CONFIG_ENV` | removes all reads of the legacy config |
+| `EMBER_SYNC_OBSERVERS` | observers are sync (async is the default) |
+| `EMBER_DROP_DEBUG_RENDER_TREE` | removes the debug render tree, in development too |
+
 ### Setting flags
 
 ```bash
 # .env
-EMBER_DEBUG_RENDER_TREE=false
+EMBER_DROP_DEBUG_RENDER_TREE=true
 ```
 
 ```js
 // vite.config.mjs
 export default defineConfig({
   define: {
-    'import.meta.env.EMBER_DEBUG_RENDER_TREE': 'false',
+    'import.meta.env.EMBER_DROP_DEBUG_RENDER_TREE': 'true',
   },
 });
 ```
@@ -89,54 +81,51 @@ export default defineConfig({
 Either one removes the whole debug render tree, in development too.
 Today it always ships, because development builds force it on.
 
-The `ember()` plugin from `@embroider/vite`:
-- reads `config/environment.js` (`EmberENV`) and `config/optional-features.json`, and defines the matching `EMBER_*` values. Existing apps get smaller builds with no changes.
-- parses `.env` values as JSON. Plain Vite gives the string `"false"`, which is truthy, so without the plugin, use `define`.
-- resolves conflicts as `define`, then `.env`, then `config/environment.js`.
+Plain Vite gives `.env` values as strings, and the string `"false"` is truthy.
+To turn a flag off, leave it out.
 
 Minimal apps have no config files, so they use `.env` or `define` like any other Vite config.
-Generators can drop the `EmberENV` key from `app/config.ts` (in `ember.nvp`, nothing reads it).
 
-### `window.EmberENV`
+### Legacy config
 
-`ember-source` no longer reads `window.EmberENV`.
-Most apps won't notice, because Embroider fills it from the same `config/environment.js` that the plugin reads.
-Apps that set it by hand lose those values.
-For those, development builds throw an error for each mismatched key, naming the `EMBER_*` flag to use.
+`window.EmberENV`, `config/environment.js`, `@ember/optional-features`, and `@ember/canary-features` work as they do today until v8.
 
-The same goes for runtime writes to `FEATURES` from `@ember/canary-features`.
-`isEnabled` stays public, but internal code uses the `FEATURE_*` constants, because `isEnabled('FOO')` can't fold.
-Beta and release builds of `ember-source` replace `EMBER_FEATURE_*` with the channel's value, so unfinished features stay out of the tarball (same as today).
+`EMBER_DROP_LEGACY_CONFIG_ENV` removes the code that reads them.
+With the flag set, development builds throw an error for each key in `window.EmberENV`, and the error names the `EMBER_*` flag to use.
 
-### Optional features
+### Unstable features
 
-`default-async-observers` is the only optional feature that `ember-source` still reads.
-Its default becomes `true`, matching the app blueprint.
-Apps that don't list it in `optional-features.json` have sync observers today, so for them the plugin defines `false`.
-
-> [!NOTE]
-> Observers are deprecated ([RFC #1115](https://github.com/emberjs/rfcs/pull/1115)) and removed in v8, along with `EMBER_DEFAULT_ASYNC_OBSERVERS`.
-
-`@ember/optional-features` is not deprecated by this RFC.
+Features in development use `import.meta.env?.UNSTABLE_EMBER_*`.
+Code behind an unstable flag can change or break in any release.
 
 ### Sveltable deprecations
 
 How deprecations work does not change.
 
-Some deprecations come with a flag that removes the deprecated feature before the major that removes it (for example, `deprecate-ember-object` from [RFC 1234](./1234-deprecate-ember-object.md)).
-These get a `const` named after the deprecation `id`:
+Some deprecations come with a flag that removes the deprecated feature before the major that removes it (for example, `deprecate-ember-object` from [RFC 1234](./1234-deprecate-ember-object.md)):
 
 ```js
-export const DEPRECATION_DEPRECATE_EMBER_OBJECT =
-  import.meta.env?.EMBER_DEPRECATION_DEPRECATE_EMBER_OBJECT ?? false;
+if (!import.meta.env?.EMBER_DROP_EMBER_OBJECT) {
+  // EmberObject
+}
 ```
 
-`true` removes the code.
-The default stays `false` until the major where that deprecation's RFC turns it on.
+The flag goes away in the major that removes the code.
+
+### What this replaces
+
+Each deprecation is a follow-up RFC.
+
+| Today | Replacement |
+| --- | --- |
+| `window.EmberENV`, `EmberENV.FEATURES` | `import.meta.env?.EMBER_*` |
+| `@ember/optional-features` | an `EMBER_*` flag per feature |
+| canary features | `import.meta.env?.UNSTABLE_EMBER_*` |
+| `config/environment.js`, `@embroider/config-meta-loader` | a normal module at `app/config/environment.js` for runtime config |
+| `import { DEBUG } from '@glimmer/env'` | export conditions for addons, `import.meta.env.DEV` for apps |
 
 ### Ecosystem
 
-- `ember-auto-import` must define the `EMBER_*` values from the config files, or classic apps lose their config. This is required before `ember-source` ships the change.
 - v2 addons can use the same pattern for their own flags.
 - TypeScript: `ember-source` declares the `EMBER_*` keys on `ImportMetaEnv`.
 - SSR, FastBoot, and the Inspector: no change.
@@ -149,9 +138,8 @@ The deprecation guide for each sveltable deprecation documents which environment
 
 ## Drawbacks
 
-- Apps that set `window.EmberENV` outside of `config/environment.js` must move that config into the build. The error in development builds finds each case.
-- A flag can't change at runtime, so a test suite that toggles a flag needs one build per value, like the ember.js CI does for `ALL_DEPRECATIONS_ENABLED` today. (With `define`, you can bring back runtime behavior, however.)
-- Every build that wants non-defaults must define the `EMBER_*` values.
+- Apps that set `EMBER_DROP_LEGACY_CONFIG_ENV` must move their `EmberENV` config into the build. The error in development builds finds each key.
+- A build that replaces a flag cannot change it at runtime. Vite in development leaves `import.meta.env` as a mutable object, so flags can change there.
 - Without a bundler, there is no way to set a flag.
 
 ## Alternatives