MUI structural inspection: TREE-equivalent walking of a live MUI application's object hierarchy

[sidick]

Problem

userdocs/Locator-Tiers-and-Limits.md's own table: for MUI applications, intuition-model's class-name walker "has no MUI recognition, so Tier 2 doesn't reach MUI gadgets at all — confirmed live that a MUI window attaches only its own single top-level object to window->FirstGadget, the same limit window.class/layout.gadget has." A MUI app is currently Tier 3 (MUIREXX, whatever ARexx commands the app itself registers) or Tier 4 (raw coordinates) only — there is no TREE-equivalent structural view into a MUI application's own object tree at all, unlike GadTools/top-level ReAction gadgets.

Proposed scope (research first, per this project's own "real functions, not guessed heuristics" rule)

This needs investigating muimaster.library's own documented introspection surface before any implementation — not assumed. Candidate starting points to verify against the real SDK docs/autodocs (not guessed):

• MUI's own class hierarchy is BOOPSI-based (MUIC_Notify/MUIC_Area/MUIC_Group/...), so OCLASS()-based class-name identification (the same mechanism ClassifyByClassID() already uses for top-level ReAction gadgets) may partially apply to whatever IS reachable.
• MUIA_Group_Child/MUIM_Group_InitChange and related family-list attributes are how a MUI app enumerates its OWN children internally — whether any of that is safely queryable from OUTSIDE the owning process (vs. only via in-process DoMethod()/GetAttr(), which this project's own no-SetFunction/no-private-struct-reading rules would rule out anyway) needs confirming against the real autodocs, not assumed.
• If no safe external introspection mechanism exists (plausible — MUI objects are far more dynamic/private than classic Intuition gadget lists), the realistic path is the same cooperative, app-side pattern already designed for ReAction's own nested-layout.gadget gap: issue Cooperative geometry port (WHERE): escape hatch for layout.gadget-nested gadgets #49's "WHERE" port concept (an application-side ARexx or similar port answering "where is this named object"), generalized to also answer MUI-specific identity questions. Worth explicitly evaluating whether Cooperative geometry port (WHERE): escape hatch for layout.gadget-nested gadgets #49's design can just be extended to cover this case rather than inventing a second, MUI-specific mechanism.

Why file now

Filed per user request as part of a general post-1.0 planning pass — MUI structural inspection is a real, currently-total gap (not even the top-level object is classified today), distinct from #49 (which is specifically about ReAction's layout.gadget nested-children limit).