Background

Several C++ source materials and stack overflow questions talk about the implementation dependent nature of char. That is, char in C++ may be defined as either an unsigned char or a signed char, but this implementation depends entirely on the compiler according to the ARM Linux FAQ:

The above code is actually buggy in that it assumes that the type "char" is equivalent to "signed char". The C standards do say that "char" may either be a "signed char" or "unsigned char" and it is up to the compilers implementation or the platform which is followed.

This leaves the door open for both ambiguity issues and bad practices including mistaking the signage of a char when used as an 8-bit number. The Rationale for C offers some reason for why this is the case, but does not address the issue of leaving open the possibility for ambiguity:

Three types of char are specified: signed, plain, and unsigned. A plain char may be represented as either signed or unsigned, depending upon the implementation, as in prior practice. The type signed char was introduced to make available a one-byte signed integer type on those systems which implement plain char as unsigned. For reasons of symmetry, the keyword signed is allowed as part of the type name of other integral types.

It would seem advantageous to close the door to even the potential of ambiguity to leave only the types of unsigned char and signed char as the two data types for the 8-bit unit. This prompted me to ask the question...

Question

Given the potential for ambiguity, why leave the char data type implementation dependent?