This task is related to a number of others, but concerns itself with how the results of transclusions are represented. Ideally we would have a "lazy" datatype that can be coerced to frequently-demanded types such as "raw input text", "wikitext with strip markers" or "html" but would maintain its "native" identity until such demand is made. That would allow a rich type (such as, say, "JSON object" or "key value pairs" or "ZObject") to be passed directly between fragment providers (one of which may generate the rich type, and the other which optionally may accept it) without necessarily coercing it to a string value in transit.
Current workarounds on-wiki include such things as "base64 encoding the string representation of the JSON blob" in order to be able to safely pass structured values between caller and callee without risking it being destroyed by being "interpreted as wikitext" en-route. Another common pattern is to stuff raw text into strip state to protect it en-route, which sometimes requires authors to manually wrap <nowiki> tags around arguments.
Ideally the type would also provide a "stripped plaintext" representation, for use when the fragment value needs to be turned into (eg) a heading ID, or an attribute value (the full value can be preserved using rich attributes, but a plain text version is provided for HTML compatibility). A fallback "plain text" version can be generated by converting to DOM and asking for the textContents of the DOM, but different types might be able to provide better stringifications. (For example, <math>H_2O</math> would generate H<sub>2</sub>O as DOM and so would naively stringify to "H20" but perhaps the fragment provider might prefer it to stringify to "H_2O" or even "H₂O".)