Correcto, el MZD está basado en OpenCar, que al final nos facilita el desarrollar sistemas multimedia para vehículos, y este provee un framework o marco de trabajo que nos provee de muchas funciones propias del coche, y esto se lee a través del canbus.
Por lo visto, a falta de probar los módulos modificables que he podido cambiar para que se visualicen ciertas aplicaciones ocultas, que se ocultan porque el canbus dice que no están disponibles, no creo que se pueda hacer gran cosa, pero los caminos de la informática son inescrutables

.
Está el caso del DVD, he colgado más arriba una captura de la aplicación de test (que por cierto nos permite hacer la diagnosis del coche, mostrando y eliminando códigos de avería (DTC). A través de esta app, he conseguido obtener un partnumber de la pieza, y googleando, me sale un página en japonés

, así que ni papa, pero en la página se puede leer las palabras CD y DVD, con lo que casi seguro tiene la capacidad física de leer DVD's, pero a la centralita le han dicho que es un lector de CD (en el resumen de aparatos instalados esta app dice DVD <not_installed>).
En cuanto introduces uno en el lector, devuelve error (que incluso registra un DTC (hay que joderse, con perdón) como disco erróneo).
Por mucho que muestre la app de DVD, el sistema seguirá escupiendo los DVD que le introduzca

.
No voy a dibujar ahora un esquema, pero imaginaos una serie de capas, en la de más abajo están las centralitas electrónicas del coche, que se interconectan al canbus mediante un gateway.
Podríamos hacer un símil con los ordenadores que tenemos en la oficina o en casa, imaginemos 3 PC, conectados por cable a un switch e intercambian mensajes entre ellos mediante protocolo TCP/IP (en el caso del coche protocolo CAN).
Por encima de esto está el ordenador que sostiene el MZD, y que también se conecta al CANbus y por lo tanto tiene acceso a toda la electrónica del coche. Digamos que esta sería una capa superior, que es con la que puede interactuar el usuario (nosotros).
El MZD a su vez está dividido en capas, en las de abajo están los módulos que se conectan con el CANbus (el coche), por encima tenemos un marco sobre el que se han desarrollado una serie de aplicaciones de usuario que nos permiten escuchar música, disponer de un navegador, etc ...
Este marco provee a los desarrolladores de software una abstracción del CANbus y de la electrónica del coche, facilitando el acceso a sus partes mediante una serie de funciones descritas en un lenguaje, en este caso de scripting, como es Javascript, complentándose la parte visual en lenguaje de marcas HTML.
Con lo que, al final, lo que manda es lo que está en las partes de abajo, más inaccesibles y difíciles de entender para nosotros.
Probablemente muchos tengáis razón y la electrónica sea exactamente la misma para todos los países y regiones, pero salen configurados "a bajo nivel" de forma distinta.
En el caso de las puertas, habrá una centralita "confort" que manejará elevalunas, cierres, espejos y demás, y esta tendrá una memoria y en esa memoria habrá una casilla donde le habrán grabado un byte que indica que el coche no lleva cierre automático de puertas, y el MZD cuando le pregunta el CANbus "oye, ¿este coche tiene cierre automático de puertas instalado? el CANbus enviará el mensaje a la centralita correspondiente, esta leerá este byte, y responderá que NO, y la respuesta llegará a la función del MZD que lanzó la pregunta, y como el valor de retorno ha sido negativo, NO mostrará las opciones de configuración en la pantalla.
Solución, conocer las entrañas de la centralita de confort de Mazda, y con el interface OBD, enviarle los comandos correspondientes para activarla.
Suposiciones ...