WordPress has several registries that describe data which wants representation in the WPGraphQL schema, and today each is handled differently (or not at all):

• register_setting() (site settings): auto-mapped as flat scalars from get_registered_settings(). No richer typing, no way to express "this int is actually a Category" (Handle default category from wordpress #1887), no models or access control beyond the group level. Tracked in Options should be treated as Models / Nodes #2459 (settings as Models / Nodes).
• User options / preferences: hand-added fields (feat: add core user admin preferences fields to User type #3571 shipped adminColor, hasRichEditingEnabled, etc. in v2.9.0). A centralized registry for mapping them is the subject of RFC feat: RFC — Centralized registry for mapping user options to the GraphQL schema #3562.
• register_meta() (post, term, user, comment meta): no bridge at all. The supported paths are register_graphql_field() or WPGraphQL for ACF. The long-standing ask is Post, term and user meta #118, which deserves its own RFC.
• Revision meta: the block editor now revises meta, which changes assumptions for any meta mapping. Tracked in Modify how meta is handled in revisions now that the block editor revises meta #3260.

These are distinct enough that they should be designed, implemented, and tested independently, but they share design questions that should be answered consistently, which is what this tracker is for:

• The opt-in convention (show_in_graphql args vs piggybacking show_in_rest)
• Mapping stored scalars to richer GraphQL types (enums, object types, connections, e.g. defaultCategory as a Category rather than an Int)
• Naming conventions (declarative field names like hasCommentShortcutsEnabled, per the feat: add core user admin preferences fields to User type #3571 discussion)
• Model layer involvement and access control (who can see which setting/meta)
• Mutation support and input typing
• How revisions interact with mapped meta (Modify how meta is handled in revisions now that the block editor revises meta #3260)

Children

• Options should be treated as Models / Nodes #2459, settings as Models / Nodes (register_setting)
• feat: RFC — Centralized registry for mapping user options to the GraphQL schema #3562, centralized registry for user options (RFC)
• Post, term and user meta #118, register_meta() to schema (needs an RFC)
• Modify how meta is handled in revisions now that the block editor revises meta #3260, revision meta behavior

Each child should produce its own RFC or implementation plan; consistency across them gets discussed here.