Making it possible to specify the subpage on a per-page basis might not be the best solution, as then this subpage does need to be specified for every TemplateData block not on the standard subpage. Some ideas I like better:

• Automagically find the source of the embedded TemplateData block, without need for any configuration. I’m not sure if it’s currently possible using Parsoid.
• Make it possible to specify additional standard subpage names. For example, a MediaWiki message would specify that TemplateData blocks are either on the /doc or the /doc/TemplateData subpage. All TemplateData that doesn’t fit in the usual /doc subpage should be on a subpage titled /doc/TemplateData—this both makes it unnecessary to maintain a per-page configuration and makes it easier to find such subpages using other tools (e.g. bots). If this solution is chosen, I think it should allow an arbitrarily large number of subpage names, for wikis that already have an inconsistent naming system (although inconsistent naming should be discouraged).
• Make it possible to specify one additional standard subpage name, which contains raw TemplateData blocks—no <templatedata> tags, no other wikitext content. Transcluding the TemplateData block would still be an on-wiki template’s job, but using a separate page could improve the editing experience without the wizard thanks to the page content model being specified to be JSON (automatic indentation, highlighting matching braces and syntax errors etc.). This wouldn’t allow sharing documentation between similar but not equivalent templates, though, as it would allow no parametrization.

Something similar to the last idea is going to happen some day, in my personal opinion. MediaWiki (partly) supports something called multi-content revisions (MCR) for quite a while now. A ticket for this already exists, see T56140: Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot. Unfortunately this technology is still relatively new and not widely used, and the TemplateData use case is more a minor one that's unlikely to get attention soon.

In T314970#8149784, @Tacsipacsi wrote:

Making it possible to specify the subpage on a per-page basis might not be the best solution, as then this subpage does need to be specified for every TemplateData block not on the standard subpage. Some ideas I like better:

• Automagically find the source of the embedded TemplateData block, without need for any configuration. I’m not sure if it’s currently possible using Parsoid.

This would obviously be the ideal, but I'm trying to work with something that can be done soon, i.e. without having to re-engineer tools. I obviously don't know entirely the details of how the visual editor works, but in testing it at least recognizes transcluded content. But that is a "pull" operation on the TemplateData, and "push" operations by widgets like Manage TemplateData are another story. Since there is a mechanism on a per-wiki basis for allowing that tool to put TemplateData in different places, it seems like the simplest solution would be to open that mechanism up to a bit more customization

• Make it possible to specify additional standard subpage names.

That could have some advantages when it comes to multi-lingual projects where editors can create JS scripts that create TemplateData, and those scripts might use some other wiki's default. But that would still prevent things like TemplateData sharing among related templates.

• Make it possible to specify one additional standard subpage name, which contains raw TemplateData blocks—no <templatedata> tags, no other wikitext content.

Limiting it to one subpage would definitely have less utility. I would also be concerned about making it JSON only code, as I can see some pretty significant advantages to retaining transclusion and magic word conditionals to make standardized collections of TemplateData more robust and flexible. So that would require wikitext processing.