A parte importante da minha frase foi:
Assim que você atualizar, as depreciações se transformarão em erros, como você disse 
Sim, estes podem ser acessados através das propriedades injetadas dos componentes, ou importando os módulos Site e User de discourse/models/user e discourse/models/site.
Ah sim, alternativa útil para passá-los através de helpers como parâmetros.
Para o meu plugin que estou desenvolvendo e executando ./bin/ember-cli não tenho nada com que me preocupar, já que estou usando o ember-cli.
Mas minha preocupação são as dezenas ou centenas de pessoas que não vão descobrir isso até que seja tarde demais, alguém que não sabe de JavaScript a CSS ou de um plugin a um componente de tema, eles não precisam se preocupar a menos que tenham JavaScript em um componente de tema.
O que eu gostaria é de um teste simples para que eles saibam se devem se preocupar com qualquer coisa. Para essas pessoas, eu recomendarei que elas iniciem um novo servidor, restaurem seu banco de dados e vejam se algo explode. Certo?
Ou eles devem apenas ativar EMBER_CLI_PROD_ASSETS: 1, fazer um rebuild e se explodir, desativá-lo novamente e, em seguida, iniciar um novo servidor para corrigi-lo.
Eu acho que você poderia consultar para ver se existem theme_fields com o tipo html ou js:
Isso funcionaria, mas configurar um servidor totalmente novo parece muito esforço. Em vez disso, eu recomendaria:
. . . A menos que você tenha passado o último ano desenvolvendo uma ferramenta para tornar “fácil” a criação de novos servidores? 
Então, o que acontecerá com aqueles que não prestam atenção a essas coisas é que elas quebrarão quando a janela de “ember-by-default” chegar e, então, eles poderão desativar essa variável de ambiente por mais um ou dois meses (e presumivelmente corrigi-la) antes que isso não funcione mais.
Restaurei um backup em um novo site que tem o tema Kanban ativado e ele está apresentando erros (eu relatei isso no tópico do kanban), tentei definir
EMBER_CLI_PROD_ASSETS: 0
e as reconstruções ainda estão dizendo:
Por que você deve fazer isso regularmente:
https://github.com/browserslist/browserslist#browsers-data-updating
que eu (acho que) reconheço como vindo do ember-cli. Existe alguma maneira de desativá-lo em novos sites?
Se eu reconstruir um site antigo, ele receberá a nova imagem base e não poderá desativar o ember-cli?
Isso é um erro de digitação na sua mensagem aqui ou um erro de digitação no seu yml? Deveria ler EMBER_CLI_PROD_ASSETS: 0
Obrigado! Mas sim, esse é um erro de digitação, mas eu o corrigi no arquivo yml. Eu apenas o copiei/colei corretamente na OP.
A verificação no código parece não ter sido alterada, mas não estou muito familiarizado com Ruby. Uma condição booleana com ENV['EMBER_CLI_PROD_ASSETS'] usará o valor dessa chave ou será verdadeira se essa chave existir?
Se for o último caso, a resposta pode ser remover EMBER_CLI_PROD_ASSETS do yml em vez de defini-lo como 0.
Isso não vai funcionar, você precisa remover a linha.
. . . espere . . .
Nenhum dos meus problemas tinha a ver com o ember-cli, mas com minha própria configuração incorreta, já que esta era uma instalação de 2 contêineres e web_only.yml não foi atualizado quando standalone.yml foi. Aqui está um PR:
O Ember CLI é agora o padrão para todas as instalações do Discourse. Quando você atualizar da próxima vez (seja através da interface /admin/upgrade ou via ./launcher rebuild app), você será automaticamente alterado para o Ember CLI.
Estamos agora executando o Ember CLI na maioria de nossa hospedagem gerenciada, então não esperamos grandes problemas. Mas se você notar alguma coisa, por favor, crie um tópico aqui no Meta e nós investigaremos.
Reconstruí um site ontem que falhou devido ao ember CLI e o corrigi removendo EMBER_CLI_PROD_ASSETS=1.
Em um momento inicial, tentei desabilitar o ember cli definindo EMBER_CLI_PROD_ASSETS=0 e tenho quase certeza de que ele ainda incluía o ember_cli e alguém me disse que você não poderia desabilitá-lo definindo-o como 0 (o que não fazia sentido, mas parecia ser verdade).
Isso é um pouco desafiador para auto-hospedeiros que têm temas antigos e nunca olham o console javascript.
Isso era verdade, mas corrigi a lógica com este último commit para que =0 funcione como esperado. Dito isso, pretendemos remover totalmente o ambiente ‘legado’ em questão de semanas, então, por favor, não use =0 a menos que seja por um período extremamente curto.
Adicionamos retrocompatibilidade para os erros mais comuns que vimos em nossa hospedagem. Por exemplo, este commit algumas semanas atrás adicionou retrocompatibilidade para Discourse.User e Discourse.SiteSettings. Este commit corrigiu alguns problemas para temas com processos de inicialização não padronizados.
Queremos tornar essa implementação o mais tranquila possível, então, se você encontrou erros na última semana ou mais, por favor, nos informe o erro exato e o código que o causou.
Ah. Que bom. Faz sentido. (Funciona como eu pensava que deveria funcionar o tempo todo. E eu não sou louco por lembrar que me disseram que não funcionava como eu pensava que deveria. São ótimas coisas!).
Acho muito difícil descobrir isso (provavelmente devido à ignorância). Quando clico na coisa que acho que deveria me mostrar o que está causando o erro, o que recebo é o código que parece ser o código que testa a depreciação, não o código que a exibe. Tentarei enviar alguns exemplos em breve.
Se precisar de ajuda para descobrir, um tópico de Support com uma captura de tela do erro seria um bom ponto de partida - então poderemos ajudar na depuração a partir daí. É provável que outra pessoa já tenha visto um erro semelhante e possa reconhecer os sintomas. 
E agora para o passo final desta saga: o sistema de compilação legado foi desabilitado. Todas as instalações do Discourse compilarão os assets usando o Ember CLI.
Esta alteração afetará apenas as pessoas que definiram deliberadamente EMBER_CLI_PROD_ASSETS=0 em sua configuração. Nesse caso, um aviso será exibido durante a compilação, e o Ember CLI será usado.