This is a placeholder for a discussion we had at the 2018 parsing team off-site (suggested by @Sbailey) about using wikitext 2.0 as a low-bandwidth transport mechanism for client-side rendering.
The idea would be that wt2.0 would be highly optimized for render speed and bandwidth, while still looking as similar as possible to the wikitext we know and love. Instead of shipping <ul><li>Foo</li></ul> to the client, we ship *Foo\n (or {*Foo*}) and render to HTML on the client.
Another related thread to pull on: currently transclusions go into differently shaped "holes" in the resulting DOM tree (without getting into all of the details, think "block" and "inline" and trust me when I say there could be about a dozen other minor variants). In order to determine the right sort of hole to leave, you need to do a server query (roughly, fetch the TemplateData or equivalent for the transclusion and find what it says). In order to do fast incremental client-side rendering, the server might want to very-slightly annotate the wt2.0 it sends in order to indicate the type of each hole. Scarecrow: all transclusions could be normalized into {{#...}} forms (T204370) and then we'd use {{i#...}} to indicate an inline transclusion, {{b#...}} to indicate a block transclusion, and other single character annotations for other hole types. This would allow client-side rendering of the annotated wt2.0 stream without further server round-trips; it would then fill in each "hole" incrementally as the user scrolled down to make each visible with additional server requests for the wt2.0 to render for that hole.