Te equivocas... (no lo vayas a tomar personal, que todo es en buena onda
).
Entiendo lo que quieres decir, y es verdad que el "espacio" es un carácter más.. pero... (he aquí el pero)... nunca ha sido tratado como un carácter más ni ha servido para lo mismo.
Esto es obvio. Nosotros las personas (que inventamos la escritura) no vemos conceptualmente el espacio como "un cáracter más". Entonces, en la historia de la computación, no lo hemos tratado así. Principalmente el espacio ha cumplido funciones especiales. Veamos un ejemplo:
C:\>attrib file.txt +r +s
Eso es un antiguo comando de MS-DOS que cambia los atributos de un archivo.. El espacio se utiliza para separar "fisicamente" los diversos componentes de la instrucción. Que pasaría si escribiera:
C:\>attrib mi archivo.txt +r +s
Nosotros que somos bien inteligentes
asumimos que el nombre del archivo es "mi archivo.txt". ¿Pero la maquina que podía "pensar"? ¿El archivo es "mi" y esta aplicando el modificador "archivo.txt"? ¿O qué hace?
El problema es la ambiguedad. Porque no se sabe con certeza que es lo que en realidad desea hacer el usuario. En la actualidad las cosas están dispuestas de tal manera que la ambiguedad es un problema más o menos resuelto. Pero debemos recordar que los estándares que nos rigen son relativamente antiguos y se crearon cuando la ambiguedad existía. Hoy día son pocas las situaciones donde el problema de la ambiguedad sigue dominando.
El pasado
¿"El" y "pasado" son cosas diferentes o es "El pasado"? En los casos donde esta ambiguedad se pueda presentar de alguna manera, es necesario hacer una distinción con el espacio. El espacio no es un carácter más.
Por ejemplo: el compilador MingW (un porte del GCC para Windows) tenía o tienen un problema de ambiguedad con archivos y rutas que contengan espacio. El nunca te marcará error. Pero es posible que piense que terminó una sentencia donde "vea" un espacio (interpretandolo como un separador), cuando en realidad ese espacio forma parte de un "nombre" en una sentencia más larga.