La inmutabilidad y la mutabilidad no pueden ser subtipos o supertipos entre sí porque violan el Principio de Sustitución de Liskov (LSP). Según la definición formal, un tipo S es subtipo de T si cualquier valor de S puede usarse en cualquier contexto donde se espera un valor de T. Aunque un par mutable contiene todas las operaciones de un par inmutable, no lo es al revés: un par inmutable no soporta las operaciones de mutación (como set-car!), lo que genera errores de tipo si se intenta usarlo donde se espera un par mutable.
El problema es más sutil en el sentido inverso. Un par inmutable tiene un contrato implícito que garantiza que sus valores no cambian, lo cual es esencial para operaciones como el hash consing. Si un par mutable se usara donde se espera un inmutable, se romperían estas garantías de estabilidad. Por lo tanto, los tipos deben ser completamente separados. Para manejar esto, los lenguajes de programación utilizan mecanismos como las clases de tipos (en lenguajes estáticos) o el tipado de pato (en lenguajes dinámicos). Estos permiten definir operaciones comunes sobre ambos tipos sin crear una jerarquía de subtipos, asegurando que el sistema de tipos verifique explícitamente la mutabilidad cuando se requiere, manteniendo así la seguridad y la corrección del programa.