La parte importante de mi frase fue:
Una vez que actualices, las deprecaciones se convertirán en errores, como dijiste 
Sí, se puede acceder a ellos a través de las propiedades inyectadas de los componentes, o importando los módulos Site y User de discourse/models/user y discourse/models/site.
Ah sí, útil alternativa a pasarlos a través de ayudantes como parámetros.
Para mi plugin que estoy desarrollando y ejecutando ./bin/ember-cli no tengo nada de qué preocuparme, ya que estoy usando ember-cli.
Pero mi preocupación son las docenas o cientos de personas que no se enterarán de esto hasta que sea demasiado tarde, alguien que no sabe de javascript a CSS o de un plugin a un componente de tema, no necesitan preocuparse a menos que tengan javascript en un componente de tema.
Lo que me gustaría es una prueba simple para que sepan si deben preocuparse por algo. Para esas personas, les recomendaré que inicien un nuevo servidor, restauren su base de datos y vean si algo explota. ¿Correcto?
¿O simplemente deberían activar EMBER_CLI_PROD_ASSETS: 1, hacer una reconstrucción y si explota, volver a desactivarlo y luego iniciar un nuevo servidor para solucionarlo?
Supongo que podrías consultar para ver si hay algún theme_fields con el tipo html o js:
Eso funcionaría, pero configurar un servidor completamente nuevo parece mucho esfuerzo. En cambio, recomendaría:
. . . ¿A menos que hayas pasado el último año desarrollando una herramienta para que sea “fácil” crear nuevos servidores? 
Entonces, lo que les sucederá a aquellos que no prestan atención a estas cosas es que se romperá cuando llegue la ventana de ember por defecto y luego podrán desactivar esa variable de entorno por uno o dos meses más (y presumiblemente arreglarla) antes de que eso ya no funcione.
Restauré una copia de seguridad en un sitio nuevo que tiene habilitado el tema Kanban y está generando errores (lo reporté en el tema de Kanban). Intenté configurar
EMBER_CLI_PROD_ASSETS: 0
y las reconstrucciones todavía dicen:
Por qué deberías hacerlo regularmente:
https://github.com/browserslist/browserslist#browsers-data-updating
que (creo que) reconozco que proviene de ember-cli. ¿Hay alguna forma de deshabilitarlo en sitios nuevos?
Si reconstruyo un sitio antiguo, ¿obtendrá la nueva imagen base y no podrá deshabilitar ember-cli?
¿Es un error tipográfico en tu mensaje aquí o un error tipográfico en tu yml? Debería decir EMBER_CLI_PROD_ASSETS: 0
¡Gracias! Pero sí, es un error tipográfico, pero lo tengo bien en el archivo yml. Simplemente lo copié y pegué correctamente en el OP.
La verificación en el código parece no haber cambiado, pero no estoy muy familiarizado con Ruby. ¿Una condición booleana con ENV['EMBER_CLI_PROD_ASSETS'] usará el valor de esa clave o será verdadera si esa clave existe?
Si es lo último, la respuesta podría ser eliminar EMBER_CLI_PROD_ASSETS del yml en lugar de establecerlo en 0.
Eso no funcionará, necesitas eliminar la línea.
. . . espera . . .
Ninguno de mis problemas tenía que ver con ember-cli, sino con mi propia configuración errónea, ya que se trataba de una instalación de 2 contenedores y web_only.yml no se actualizó cuando standalone.yml sí lo hizo. Aquí tienes una PR:
Ember CLI es ahora el predeterminado para todas las instalaciones de Discourse. Cuando actualices la próxima vez (ya sea a través de la interfaz de usuario /admin/upgrade o a través de ./launcher rebuild app), se te cambiará automáticamente a Ember CLI.
Ahora estamos ejecutando Ember CLI en la mayoría de nuestros servicios de hosting gestionado, por lo que no esperamos problemas importantes. Pero si notas algo, por favor crea un tema aquí en Meta y lo investigaremos.
Reconstruí un sitio ayer que falló debido a ember CLI y lo arreglé eliminando EMBER_CLI_PROD_ASSETS=1.
En un momento temprano, intenté deshabilitar ember cli estableciendo EMBER_CLI_PROD_ASSETS=0 y estoy bastante seguro de que todavía incluía ember_cli y alguien me dijo que no podía deshabilitarlo estableciéndolo en 0 (lo que no tenía sentido, pero parecía ser cierto).
Esto es un poco desafiante para los autoalojadores que tienen temas antiguos y nunca miran la consola de javascript.
Eso era cierto, pero arreglé la lógica con este último commit para que =0 funcione como se esperaba. Dicho esto, tenemos la intención de eliminar por completo el entorno ‘legacy’ en cuestión de semanas, así que por favor no uses =0 a menos que sea por un período de tiempo extremadamente corto.
Hemos agregado compatibilidad retroactiva para los errores más comunes que vimos en nuestro hosting. Por ejemplo, este commit hace un par de semanas agregó compatibilidad retroactiva para Discourse.User y Discourse.SiteSettings. Este commit solucionó algunos problemas para temas con procesos de inicialización no estándar.
Queremos que esta implementación sea lo más fluida posible, así que si has encontrado errores en la última semana aproximadamente, por favor, infórmanos del error preciso y del código que lo causó.
Oh. Estupendo. Tiene sentido. (Funciona como pensé que debería funcionar desde el principio. Y no estoy loco por recordar que me dijeron que no funcionaba como yo pensaba que debería. ¡Son cosas geniales!).
Me resulta muy difícil averiguarlo (probablemente por ignorancia). Cuando hago clic en la cosa que creo que debería mostrarme qué está causando el error, lo que obtengo es el código que parece ser el código que prueba la depreciación, no el código que la exhibe. Me esforzaré por enviar algunos ejemplos pronto.
Si necesitas ayuda para averiguarlo, un tema de Support con una captura de pantalla del error sería un buen punto de partida; a partir de ahí podremos ayudarte a depurar. Es muy probable que alguien más haya visto un error similar y reconozca los síntomas. 
Y ahora, el paso final de esta saga: el sistema de compilación heredado ahora está deshabilitado. Todas las instalaciones de Discourse compilarán activos utilizando Ember CLI.
Este cambio solo afectará a las personas que hayan configurado deliberadamente EMBER_CLI_PROD_ASSETS=0 en su configuración. En ese caso, se imprimirá una advertencia durante la compilación y se utilizará Ember CLI.