There's something that is underused in the OpenType specification : the possibility to bind different glyphs according to a given language. If we had semantic characters encoded instead of just characters encoded for their core visual aspect, we could make the difference between cultures, according to user's locale preferences or according to the document's language (provided that it is tagged properly in its metadata).
But we've all seen that language tagging fails almost always. Language tagging is generally false, or simply not defined by authors, and automatic language identification most often works better (but with a significant share of failures too). For this reason, it is still best to create documents encoded using visually encoded characters rather than semantically encoded. Yes this means that the semantics of the characters will remain ambiguous, but at least users will see the glyphs matching what was meant by the document author in his own document and in his language (even if the application used to view it cannot completely guess that information, even from existing language tags which are generally wrong, or lost during the transfer when working with downloaded documents, as the language will then become the prefered one used by the viewing/editing user in his own system). Do we really need new semantic characters that will render differently according to a language indication that is not even reliable ? And that will create a lot new confusable and will cuase new security problems (imagine the effect if the solidus-slash is not distinctable and used in a filename or URL because it was encoded semantically as a division symbol, and then an encoding conversion changes it in an ASCII pathname separator ? Same problem with the colon (probably even more critical if it allows accessing to another URI scheme or to an hardware device).
