> Suggested possible ways forward:
> 
> * Exclude all subpages except those explicitly marked as templates, e.g by magic word or category
> * Include all subpages except those explicitly marked as not being templates, e.g. by magic word or category

Neither of these options are imho maintainable or author-friendly. Alternative ideas (from T98562).

> * Filter out /doc (hardcoded).
>  * Principally not as ugly as one might think, since TemplateData does this as well. Though TemplateData only uses that hardcoded value to discover related pages in the graphical interface. It is in no way enforced server-side or encouraged in its interface when inserting/editing template data.
>  * We'd have to filter it client-side, which means the number of results shown is inconsistent. To avoid false positives with template names that actually end in "/doc", we'd only remove results if the other title is also in the list. (E.g. "Template:Dac/duc/doc" or something like that.)
> * Filter out results that are transcluded in other results.
>  * Requires an additional query somewhere, but might be a smart way to do it. We'd only omit results that are transcluded by others. So "Template:Foo/doc" would be omitted because according to the link tables, "Template:Foo" (also in the suggestions) transcludes "Template:Foo/doc". This doesn't work well because documentation pages themselves often make use of various other templates. So any template used in the preview, examples, or documentation would never show up in the suggestions.
> * Filter out results that transclude template data.
>  * Not sure how this would work, but since the same duplication is also present in the page-property index (which is where template data is stored), we can detect that Foo and Foo/doc both have (the same) template data. We may be able to de-duplicate results that way (and pick the one that sorts higher, or the one with a shorter name, aka not the helper page that tends to be a sub page).

And of course {T56140} – which I'd say is the ideal solution. And is quite feasible to implement.