Bug relates to a topic in 11/18 site-content conf-call & earlier
discussion in "URL structure sanity check" public email thread, which
referenced these URLs based on the proposed /apis URL structure:
https://github.com/mike-sierra/webplatform/blob/master/urls.txt

See Paul Irish's comment from thread: "I feel like the larger
issue is one of granularity. There simply isn't a good reason all
the PerformanceTiming events (for example) should get their own
page. performance.timing deserves ONE page that's comprehensive."

Agree there's a benefit to avoid tiny fragmented pages, and to
consolidate wherever possible to provide optimum context for reader.

Question that needs clarity: in cases where child member pages feature
only small snippets of content, can we:

(a) Programatically move the structured content to embed within the
parent page?

(b) Simply reflect the content on the parent page, while keeping the
longer-form child page?

Inclined to think the latter might be better, but user might need hint
if click-thru to child page features info not reflected on parent page.

In both cases, explore opportunities to express routine info more
tersely if they appear on parent pages. E.g., small icons rather than
tables for whether events bubble, w/rollover text hints if unclear.
Or assume away mundane default info, e.g., only noting when events
don't bubble.

Or, can a tool distinguish whether a unit of content:

(a) meets a sufficient threshold weight to justify a separate child
page?

(b) features certain kinds of info inappropriate to cram onto the
parent page, such as code examples? E.g., anything other than a
routine summary & data type?

Might be a significant issue when importing structured content that
would otherwise generate numerous child pages.

This also relates to some prior discusion of the /apis URL structure:
no need to represent constants and exceptions on dedicated pages the
way you often do for methods, properties & events.

any other large issues this didn't capture, please comment away.