Hm the second one is only relevant for output.
I think this is a fundamental misunderstanding: The "original" one is not for output but is the primary value for interpretation, for understanding whether a value in Wikidata is correct of fake, or a software conversion error, or what. If I want to learn something in Wikipedia, I have to have access to this information. Having access to this I can understand whether to seemingly different values from the same source are justified or an error (like in the example from previous mail that 100 +/- 50 and 100 +/- 0.1 can be both valied for the same quantity and the same source observations).
I view the "roughly unreliably with lots of heuristics normalized converted" version the secondary. It has its uses, but I would in fact put it second and show it only with a large warning banner that this version contains lots of unwarranted assumptions which may or may not hold. But I don't care which is primary or secondary, I only want to encourage you not to forget the "data" in wikidata over implementing the essential search, retrieval, conversion, etc. functionality.
:-)
In an ideal world all data would be in a fully convertible state and no-one would simply use significant digits to express margins of error, reliability, tolerance etc. But I have not encountered this world yet.
Why not using the Term outputformat as a pattern just like Excel, OpenOffice, and LibreOffice do? This could include the number of digits behind the comma, the optional accuracy/whatever and the unit. This will be fine for the API, and the MW-Syntax.
I don't care how the information is encoded, if you develop your own language to encode information in a string and provide a syntax for that that is fine. Only already within Microsoft products the "formatting strings" are only similar, but not fully compatible, and I have doubts that this is a good way for global interoperability.
Gregor