De acuerdo, voy a responder a los problemas que estás planteando aquí por separado. Entiendo por qué los estás vinculando, pero espero que puedas ver por qué son cuestiones distintas.
Entidades HTML en notificaciones por correo electrónico en texto plano
lo más adecuado sería que los mensajes de correo electrónico fueran multipartite, con una versión en texto plano (text/plain) renderizada desde markdown y una versión separada en text/html.
Así es como funcionan actualmente las notificaciones por correo electrónico de Discourse. Si miras el “original” de una notificación por correo de Discourse, verás que hay una versión de texto y una versión HTML.
Parece que estás diciendo, aunque aún no lo tengo del todo claro, que estás recibiendo entidades HTML en la versión de texto plano de las notificaciones por correo electrónico de Discourse, lo que significa que ves las entidades HTML reales en el cuerpo del correo cuando lo ves en un cliente de correo que no soporta HTML. ¿Es eso lo que quieres decir? ¿Podrías compartir una captura de pantalla de esto desde un cliente de correo (que no soporte HTML)?
Si este es el caso, este es un problema específico de la generación y formateo del contenido de los correos electrónicos de Discourse, y sería mejor separarlo en un tema más específico en #soporte o #contribuir:bug.
HTML en las publicaciones de Discourse
Estás planteando un problema relevante, pero desde una perspectiva técnica, la cuestión radica en cómo Discourse aborda el contenido importado en general. El valor predeterminado actual para el contenido importado es HTML, no markdown.
Otros contextos en los que puedes ver esto es el plugin de sondeo RSS, que, al igual que el plugin WP Discourse, importa HTML en el contenido de la publicación. Ten en cuenta también que la configuración del sitio embed support markdown está desactivada por defecto y todas las demás configuraciones del sitio relacionadas con HTML incrustado en las publicaciones (por ejemplo, allowed embed selectors).
Estoy adivinando en parte, pero la razón más probable de esta decisión estratégica tomada en los primeros días de Discourse para manejar contenido importado fue una combinación de simplicidad y fidelidad, es decir, las conversiones de HTML a markdown serán imperfectas. Hay una excepción clave a esto que mencionaré a continuación.
El plugin WP Discourse podría intentar convertir el HTML de las publicaciones de WordPress a markdown antes de enviarlas a Discourse. Sí, existen bibliotecas PHP existentes que convierten HTML a markdown, pero nunca es tan simple como eso al convertir un lenguaje de marcado, especialmente considerando los diferentes sabores de markdown.
De hecho, que el plugin WP Discourse intente manejar la conversión sería un error, considerando que ya existe un convertidor personalizado HtmlToMarkdown en Discourse. Actualmente, este convertidor maneja la conversión de HTML a markdown en correos electrónicos importados en Discourse. Si el HTML de las publicaciones de WordPress se convirtiera a markdown de Discourse, tendría que ser manejado por ese convertidor.
Actualmente, el plugin WP Discourse utiliza la API de Discourse para publicar las entradas, es decir, el endpoint /posts. Así que esencialmente lo que estás diciendo es que quieres que se agregue soporte para el convertidor HtmlToMarkdown al endpoint /posts de Discourse (es decir, como un parámetro de consulta opcional). Podrías abogar por esto y, si se implementa, el plugin WP Discourse lo adoptaría como una configuración opcional.