The important part of my sentence was:
Once you update, the deprecations turn into errors, as you said 
Yep these can be accessed via the injected properties of components, or by importing the Site and User modules from discourse/models/user and discourse/models/site
Ah yes, useful alternative to passing them through helpers as parameters.
For my plugin that I’m developing and running ./bin/ember-cli I have nothing to worry about, since, I’m using ember-cli.
But my concern is the dozens or hundreds of people who aren’t going to find out about this until it’s too late, someone who doesn’t know javascript from CSS or a plugin from a theme component, they don’t need to worry unless they have javascript in a theme component.
What I would like is a simple test so that they know whether they should have anything to worry about. For those people, I’ll recommend that they spin up a new server, restore their database and see if anything explodes. Right?
Or should they just turn on EMBER_CLI_PROD_ASSETS: 1, do a rebuild and if it explodes, turn it back off, and then spin up a new server to fix it.
I guess you could query to see if there are any theme_fields with the html or js type:
That would work, but setting up a whole new server seems like a lot of effort. Instead, I would recommend:
. . . Unless you’ve spent the past year developing a tool to make it “easy” to spin up new servers? 
So what will happen for those who don’t pay any attention to this stuff is that it’ll break when the ember-by-default window hits and then they can turn off that ENV variable for another month or two (and presumably fix it) before that doesn’t work anymore.
I restored a backup to a new site that has Kanban theme enabled and it’s getting errors (I reported it on the kanban topic), I tried setting
EMBER_CLI_PROD_ASSETS: 0
and rebuilds are still saying:
Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating
which I (think I) recognize as coming from ember-cli. Is there some way to disable it on new sites?
If I rebuild an old site is it going to get the new base image and not be able to disable ember-cli?
Is that a typo in your message here or a typo in your yml? It should read EMBER_CLI_PROD_ASSETS: 0
Thanks! But yes, that’s a typo, but I got it right in the yml file. I just copy/pasted it correctly in the OP.
The check in the code seems to be unchanged but I’m not very familiar with Ruby. Will a boolean conditional with ENV['EMBER_CLI_PROD_ASSETS'] use the value of that key or will it be true if that key exists?
If it’s the latter, the answer might be to remove EMBER_CLI_PROD_ASSETS from the yml rather than set it to 0.
That won’t work, you need to remove the line.
. . . wait . . .
None of my issues had to do with ember-cli, but with my own misconfiguration, since this was a 2-container installation and web_only.yml didn’t get updated when standalone.yml was. Here’s a PR:
Ember CLI is now the default for all installations of Discourse. When you next update (either via the /admin/upgrade UI, or via ./launcher rebuild app), you will be automatically switched to Ember CLI.
https://github.com/discourse/discourse/commit/1b622667bc8c08e56707b3f0a43828808d024787
We’re now running Ember CLI in the majority of our managed hosting, so we don’t expect any major issues. But if you notice anything, please do make a topic here on Meta and we’ll investigate.
I rebuilt a site yesterday that failed due to ember CLI and fixed it by removing EMBER_CLI_PROD_ASSETS=1.
At one point early on I tried to disable the ember cli by setting EMBER_CLI_PROD_ASSETS=0 and I’m pretty sure that it still included ember_cli and someone told me that you couldn’t disable it by setting it to 0 (which didn’t make sense, but seemed to be true).
This is a bit challenging for self-hosters who have old themes and never look at the javascript console.
That was true, but I fixed the logic with this latest commit so that =0 works as expected. That said, we intend to totally rip out the ‘legacy’ environment in a matter of weeks, so please don’t use =0 unless it’s on an extremely short-term basis.
We’ve added backwards compatibility for the most common errors we saw across our hosting. For example this commit a couple of weeks ago added backwards-compatibility for Discourse.User and Discourse.SiteSettings. This commit fixed up some issues for themes with non-standard initialization processes.
We want to make this rollout as smooth as possible, so if you’ve run into errors in the last week-or-so, please do let us know the precise error, and the code which caused it.
Oh. Hooray. That makes sense. (It works like I thought it should all along. And I’m not crazy for remembering that I was told it didn’t work how I thought it should. These are great things!).
I find it really hard to figure that out (likely due to ignorance). When I click the thing that I think should show me what’s causing the error, what I get is the code that appears to be the code that tests for the deprecation, not the code that exibits it. I’ll endeavor to send some example(s) soon.
If you need a hand figuring it out, a support topic with a screenshot of the error would be a good starting point - then we can help with debugging from there. Chances are, someone else has seen a similar error, and may recognise the symptoms. 
And now for the final step of this saga: the legacy build system is now disabled. All Discourse installs will compile assets using Ember CLI.
https://github.com/discourse/discourse/commit/12980418ae5b947fb67e0427d3afe3fd224927c4
This change will only affect people who had deliberately set EMBER_CLI_PROD_ASSETS=0 in their config. In that case, a warning will be printed during the build, and Ember CLI will be used.