[As discussed with Denny just now.]

A: Inside the JSON blob [no-one has done this]

• i18n via either one big blob with inline language switching or lots of little blobs, one per language

Pros

• Conceptually simple
• Quickish to implement
• If one blob, allows for treating ZObjects like MW pages (categories, etc.)

Cons

• Storage size; maximum 2MiB blob size overall will mean hard to support lots of languages (300 languages x 2KiB of wikitext x 200% JSON expansion bloat cost ~= 1.2MiB of wikitext alone, taking much of the space; probably the effective limit)
• Inefficient processing of heavy JSON blobs with wikitext that only the ZObject view renderer cares about, not the ZFunction processor, etc.
• Fiddly to provide the editing experience users would expect.
• Some things would have complex implementation vs. expectation issues. (What does {{DISPLAYTITLE}} do? What does NOINDEX do? What does {{#REDIRECT}} do? Etc.)
• Would need to re-implement big bits of MW (history/RC/…) and hook into others (parser functions, transclusion, …)
• Re-using/extending the Translate extension not possible (no wikitext source page, no sub-pages, not concept of a "master" defintion)
• Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about.

B: In a secondary wikitext MCR slot [see SDC for example implementation]

• Assembled onto the view page by the page handler
• One big blob with inline language switching

Pros

• Conceptually very simple
• Quick to implement
• One blob, allows for treating ZObjects like MW pages (categories, etc.)
• Things that aren't the front-end renderer can just ignore the slot entirely (no need to cascade/execute updates to functions/implementations/etc.)
• Storage size issues deferred to later (300 languages x 6.66 KiB of wikitext would be max)

Cons

• Large bits of MCR not yet implemented; we might need to build this ourselves, or we might avoid using any bits that aren't yet there. How would we know?
• Fiddly to provide the editing experience users would expect. Would it be OK to provide an "edit" tab that only shows you the description and nothing else (like Category pages)?
• Can't create/edit a page with both slots at once; would need to be two edits (see MCR use for UploadWizard), which is a bit icky
• Can't do a slot for each language
• Re-using/extending the Translate extension not possible (no sub-pages, not concept of a "master" defintion)
• Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about.

C: As a parallel associated namespace wikitext page [no-one has done this]

• Sort-of-semi-transclusion is assembled onto the view page by the page handler somehow
• One big blob with inline language switching

Pros

• Native/expected editing experience for doc pages (they're just wikitext pages), e.g. VE
• Things that aren't the front-end renderer can just ignore the parallel pages entirely (no need to cascade/execute updates to functions/implementations/etc.)
• No need to fix this for everyone; we could do just enough to make it work for us, probably?
• Storage size issues entirely gone (if anything, giving people too much rope…)
• Able to protect ZObject only without protecting the documentation

Cons

• Different/diverging edit history of doc + reality
• There's a reason this RfC has been untouched for six years
• So much of MW assumes namespaces exist as singletons (Special:) or pairs (Foo: and Foo_talk:); adding a third (ZObject:, ZObject_talk: + ZObject_doc:) will likely be a big source of on-going issues unless we upstreamed this into Core as a well-known, widely-used feature. - See T12647 and T39865

D: As wikitext sub-pages of a non-wikitext page [no-one has done this]

• Sort-of-semi-transclusion is assembled onto the view page by the page handler somehow
• Re-using/extending the Translate extension potentialy possible (but how would we add the concept of a "master-for-now" defintion?)

Pros

• Should be easy enough
• Native/expected editing experience for doc pages (they're just wikitext pages), e.g. VE
• Things that aren't the front-end renderer can just ignore the sub-pages entirely (no need to cascade/execute updates to functions/implementations/etc.)
• Easy to ignore /foo,/bar,/bang languages you don't speak from watchlist/RC/…
• Storage size issues entirely gone (if anything, giving people too much rope…)
• Able to protect ZObject only without protecting the documentation

Cons

• Different/diverging edit history of doc + reality
• Different/diverging edit history of doc in different languages
• Some things would have complex implementation vs. expectation issues. (What does the transcluded {{DISPLAYTITLE}} do? What does NOINDEX do? What does {{#REDIRECT}} do? Etc.)
• MW assumptions about namespace content typing and how sub-pages work might be a challenge.